LRC-5 (Define Exit Node reward model)

[necro-nemesis]

Nodes operating as exists appears to require a reward system based on performance. Simply providing a flat increase to exits is challenging and undesirable as it requires some form of performance monitoring.

It appears exit performance motivators are a requirement to earn higher reward otherwise nodes posing as exits carry the potential to undermine SNs. By claiming to be the higher rewarded exit but potentially under delivering the situation becomes one of over compensation for under performance.

Under delivering on an exit would be a motivator as it would reduce risk of infraction through reduced traffic and reduce the cost of operation. The notion of complete subsidization of exit nodes from block reward additionally poses scaling challenges. A more balanced approach may be in the creation of an open market similar to the manner in which VPN’s advertise and provide services for a fee; in this case offering access to exits or premium access.

In light of what appears to be a perverse condition I wish to open a discussion on exits looking at motivating performance, motivating participation, establishing a scale-able reward system and harmonizing costs with eco-system benefits.

[jagerman]

I have been thinking for some time that there is a substantial advantage to using a market-based approached to exits, either supplementing or instead of having exits be free.

There are a few things that I quite dislike about the free-to-play model (with backend payments from the block reward for exits). First, it provides no incentive at all for anyone to create "good" exit nodes. Rather the incentives are completely reversed: being an exit gets me a reward, but every byte of exit traffic I actually care increases my cost (higher server load, bandwidth costs, takedown notices, etc.). Thus the profit-maximizing exit operator has an incentive to sign up for an exit node but then wants to provide the bare minimum service on that exit.

Second, the idea of a minimum level of standard that we can enforce seems like a pipe dream. The whitepaper talks about doing random search queries but this seems incredibly gameable: since the list of search engines accessed has to be included in the software, it would be pretty easy to just open up connections to those sites and drop everything else, and there is a pretty strong incentive to do exactly that.

Third, when you set the price for additional use below the cost of that additional use you get an inefficient level of use (i.e. too much), which degrades the quality of the service. We can expect with totally free access that nodes and/or exits are just going to be running at peak capacity constantly, which means that every additional user is going to make the exit system slower and slower for everyone. Most of this traffic, though, isn't useful traffic: it's junk that people shove over it either for malicious purposes or "just because".

Fourth, paying exits from the block reward doesn't scale well. Assuming we kept the 28 LOKI block reward and gave 45% to exits (as has been suggested elsewhere) we have a maximum exit payout of 28×720×45% = 9000 LOKI/day to pay for all exit operators. It also requires minting more LOKI to pay the rewards. (And minting is not free over the long term: it effectively means of eroding the long term value of the currency, which means exits will be earning at the expense of long term LOKI holders).

A paid system, where we could provide a built-in mechanism for paying for service and proving payment via the loki blockchain, solves all of these problems:

• suddenly there's a big incentive to make your exit work well to attract (and keep) paying users
• there is a built-in incentive to not drop traffic (if you do you lose revenue)
• we instantly turn away a good amount of useless traffic (botnets, spammers, etc.) because those people aren't willing to pay.
• it allows product differentiation rather than requiring that everyone provide exactly the same service. You could have one exit that offers 1MB/s accounts for 10 LOKI/month and another offering 50kB/s for 2 LOKI/month.
• It scales to whatever the market demands
• It doesn't require any increase to the emissions to pay exit providers
• It gets people using LOKI to actually pay for services, which is a very important thing for Loki's long-term value.
• It doesn't require us to waste time playing whack-a-mole to try to monitor and punish cheating.

[necro-nemesis]

This model makes sense to me. If I look at what Lokinet adds to the platform, exit node traffic is more about the ends than the means. To clarify this statement what I am saying is there is more interest in what lies at the ends of the connection outside the network vice what facilitates it in the middle. That's not to say I am opposed to offering this capability as offering it should bring a great deal of attention but I am adverse to the idea of over subsidizing it internally on an ongoing basis for what I see it offering back to the platform in the long term.

I can envision an exit operator viewing exits from a business perspective the same way a VPNs offers access and benefiting from a model which is rewarded for delivering performance. Lokinet properly resource is a compelling alternative to other privacy options but I wouldn't go so far as saying it's beneficial enough to fully subsidize nodes particularly when scaling presents a challenge and there is no means to ensure those resources will be provided in return for that subsidy. Possibly partial subsidy to bootstrap use may be in order but it's a slippery slope as I am concerned that if misused it could in fact undermine SN participation if left unchecked and just end up costing the network more for less.

[Lucifer1903]

Interesting ideas, I definitely think this should be explored in more detail. One thing that would be beneficial is payment to allow SMTP traffic. This would prevent spam emails from being sent over lokinet.

[notlesh]

I'm optimistic about a market-based approach for paying for exit traffic. This both fixes many spam- and Sybil-related problems as well as aligns the incentives of various participants in a constructive way.

There is a fundamental difference between allowing two counterparties to exchange currency in exchange for services vs. feeding off of the block reward. The former scales directly with respect to the number of participants while also allowing competition to keep costs low and performance high. The latter has scaling characteristics that are, at best, loosely related to the utilization of the network, and at worse are more related to price volatility and are generally inflexible. Perhaps most importantly, a market-based system provides a very strong buy-pressure for Loki, which should help provide fundamental value for it.

While this potentially solves a lot of the challenges we've looked at in terms of keeping participants honest/constructive, I'd like to point out that it doesn't address the related problem of Service Nodes handling routing traffic. While that is a very different "problem space," we do need to make sure that the incentive structure does not cause undesirable behavior and also that the scaling characteristics of their rewards do not bottleneck the network as it grows.

[William-E-Coyote]

Appreciate this discussion. Seems to me that the importance of the LOKI.net is to allow a place to build Privacy based SNApps. SNApps on the LOKI.net are significantly more private than any traffic that exits the LOKI.net. Furthermore, I have been reading, and trying to understand, that there are actually very few TOR exit nodes that have high volume of traffic and if someone builds a few TOR exit nodes as high volume nodes, they will have a significant amount of traffic passing through their nodes. Therefore this gives them the ability to determine the identity of the users and reduce the privacy of the individuals using their nodes. I accept that a LOKI SN or EN has a much higher cost to deploy, therefore will have a much higher security. But this security would still be mitigated if there are few high bandwidth EN and multiple low bandwidth EN. If the EN was receiving income based on the traffic through the node, this would further decrease the cost of the exploit. On the other hand, if EN were paid for volume of traffic, there would be competition for traffic, and security would be increased.

Sambuddho Chakravarty (2014) Traffic Analysis Attacks and Defenses in Low Latency Anonymous Communication http://www.cs.columbia.edu/~angelos/Papers/theses/sambuddho_thesis.pdf

[William-E-Coyote]

Is it cost effective to add an incentive based EN structure? (Is the juice worth the squeeze?)

If the first question is, "Do we need an incentive based EN structure?" and the answer is yes, then the second question is, "How are we going to create an incentive based EN structure?" It seems to me that this type of structure would need a robust micro-payment capacity. My understanding is that micro-payments on a cryptonight protocol would increase the blockchain size by an order of magnitude. Perhaps BLINK and/or BURN offers a better solution.

Also, the LOKI.network is not dependent upon the underlying coin structure. Therefore, it would be possible to radically change the underlying coin without disrupting the LOKI.network or the reward structure.

Therefore, Is it cost effective to add an incentive based EN structure? If there is a simple solution through BLINK and/or BURN, or any other method, then of course, lets do it. But if we have to redevelop the coin structure, then perhaps not. But again, perhaps rewriting the coin structure is the best way forward.

My goal, is to be involved with a coin project that has a way of charging micro-payments for privacy traffic and service. To me, this is how the internet has to evolve and any project that creates this system has the capacity to be the next US dollar. Really! Our present day economic system is based on the cost of OIL in US dollars. Our economy will switch from OIL to DATA. Therefore I am 100% behind any arguments for adding micro-payments.

[Lucifer1903]

How about using the blink system to create payment channels? The client creates and signs a transaction and sends it to the EN it wants to use. The EN also signs the transaction and uploads it to the mempool with a time lock, opening a "blink payment channel". This transaction doesn't actually send loki anywhere it just stays locked in the mempool so it can't be spent in another transaction. As EN bandwidth/services are being used the client signs new transactions and sends them to the EN. Each transaction would contain the full payment due to the service node since the chanel was opened. When the payment channel is closed the EN signs and submits the last transaction to the mempool. This transaction removes and replaces the locked loki from the mempool settling the balance between the EN and client in one payment instead of multiple micro-payments.

[Lucifer1903]

I would just like to say that if EN services are going to be paid for by users instead of a block reward (which actually makes the most sense) then I am for reducing the block reward to 20 Loki per block.

All SN receive 19 Loki block reward, Foundation receives 1 loki, and any node that provides EN services gets paid by the users of those services.

[Lucifer1903]

Although having free exit node services paid from the block reward would drive awareness about the Loki project. If there is going to be a free EN service maybe it should be limited to accessing websites and capped at a maximum speed for free users. Other types of traffic and higher speeds can be paid for, whether it's directly to the ENs or indirectly via burning.

[SomethingGettingWrong]

Method of incentive payments

Step one all exit nodes public key is in a list viewable on loki blocks. Step two a person can copy an exit node public key. ( this is similar to selecting a proxy) Step three Loki browser generates a session ID with a public key
Step four The exit node accepts and directs packets that contain a unique signature hash generated from your public key and its public key and prove transaction upon payment by generating a hash. Step five send a blink payment to the public key of the exit node of a certain amount. It will only accepts and directs packets from that seed to exit If the session Id and its public key and prove transactoin created hash match!

If the exit node performs like shit... people will stop using it... .. if no one uses it.. then the exit node shouldnt recieve payment.

Exit node payment should be split by a quorm agreement based upon which exit node has the most traffic!

The most traffic will come about based on if it is fast and optimal and providing good service!

[dwarner5522]

I like the points jagerman made above.... particularly the points about it scaling. This seems like a better approach to me now rather than restructuring the block reward to compensate EN's. The point made about increasing LOKI's long-term value by using it to pay for services like these is an important one too that I think gets easily overlooked.

[Lucifer1903]

I'm guessing that with a market based model it would greatly reduce the likelihood of ENs being shut down by VPS providers due to abuse reports?

Should there be a setting which allows ENs to limit the amount of users so they can can guarantee quality of service? QoS could also be incorporated into ENs so that traffic can be balanced between users.

When an EN first comes online the network could test the maximum speed of the EN and publish it along with the maximum amount of users and the minimum speed a user should get from that EN. A small amount of the block reward could be used by regular SNs to pretende to be a user and test the EN periodically to make sure they are meeting the the minimum and to also publish the average speed of each EN.

[necro-nemesis]

The open market strategy goes something like this:

We've briefly discussed freemium options for exits. One could be prioritizing traffic but the more favorable approach could be limiting free accounts to tcp.

Under a market based approach market forces should kick in with the provider attempting to make their services sought after by providing quality access at a competitive price. We've seen what this amounts to with free VPN's and historically people who want quality are accustomed to paying for it to get a valued level of service.

QoS theoretically could be orchestrated by the Exit provider given the right tools to exercise control over what they are offering for various service plans. In an open market they would have full control over offering plans based on how they decide to build their marketing strategy and profitability structure.

Free access may be an option they use to get people started. To take it to the point where it's on par with the quality of service people are accustomed to, and accustomed to paying for, there would be a means to ramp it up through being properly resourced under a pay for QoS model. The Exit operator would have the option of scaling it up to what they feel their customer wants and are willing to pay for from the service.

[Lucifer1903]

@Haafingar if a market based system is implemented would the foundation consider taking fiat payments and paying ENs in loki on behalf of users? Similar to how in app purchased with the foundation burning loki on behalf of users is being considered for Session?

[crypto-ali]

I really like @jagerman reply regarding a paid setup to use EN. It solves a lot of problems including keeping most spammers and malicious attackers from using the Loki ENs since it wouldn't be profitable to do so.

[GraftSpy]

I like the market based model too. It would give Loki a very strong new use case.

BUT, how would the market base model be enforced? What if I sign up for 1mb/s at 10 loki/month, but then the node goes offline. . . Do I have to "sign up" to an exit node? Are there security concerns with this model?

Could we also have an unpaid option that is 56kb so that people can try it for free? Or does that risk a dial-up attack? [dumb joke, but serious question. Maybe Foundation could run the free node (or nodes)].

[KeeJef]

The market based approach ticks all the boxes except one, i'm a very confident people wont use it. Consider the points below

• Tor exit nodes are free, transitioning users from a free to paid service is extremely difficult
• Onboarding into the Loki cryptocurrency is extremely difficult for average users
• Multiple other crypto projects have tried this and have been largely unsuccessful, See Orchid, Lethean, Mysterium.

In my mind the better thing to do might just be to make Service Nodes voluntarily be Exit Nodes, this is how it works in Tor, but in Loki its better since Service Nodes would still get their normal rewards, but those operators who have the capacity and who care about supporting the network just become Exits. We can do some minimal testing, to ensure those who claim exit status are operating, but people wont be trying to game the system to earn more rewards. If that provides disappointing results i think we could revisit market based models.

[SomethingGettingWrong]

I think this is a good idea however.. if we just go ahead and pay exit nodes a lil more and normal nodes a little less out of hte block reward at the end of the day if they were gonna support the network then they were going to do it weather paid extra are not.... however... even if we have bad performing exit nodes... at least there are more exit nodes no?

I say just roll with paying them a little more then normal nodes.. and later figure out a way to "test them wihtout exposing meta data"

Thats the way tor works anyway. it is free.. the payments must be from the network.. if its from the user base they will not use it!!!!!

For all we know it might perform better then we thought despite bad actors.

There is nothing you can do about bad actors completely! if every exit node is getting paid the same at least you will have more exit nodes... then just the ones that perform better.

heck maybe users LOKINET ADDRESS can bandiwdth test diffrent paths... and block out the exit node doing bad automaticly and it just ignore bad exits. at the end of the day the real good exits will work and the slow crappy exits willl still be there even if slow.

nothing is perfect.

I dont see why people wouldnt upgrade and provide an exit node with the amoutn of loki there getting.. (as an in crease from removing mining)

If we keep the rewards the same.. i can see why they wouldnt... but extra emission has to count for something..

[necro-nemesis]

Another option may be a freemium based approach that allows exits an external source of revenue while enticing people to use Lokinet for free. TCP traffic (which TOR only handles) is free; subsidized and validated on a random testing basis, UDP can be purchased from the node operator.

[KeeJef]

That could work well, for example the voluntary exits could by default only deal with TCP packets and the paid exits could deal with all protocols

[necro-nemesis]

It would be interesting to know how the breakdown of volume of traffic looks to appreciate what value can be attributed to protocols other than TCP. My appreciation of the situation is that most streaming would ideally use UDP vice TCP.

[Lucifer1903]

Okay if we are going to do this how about we provide a small incentive.

When pulse is implemented SNs will be receiving 18.9 per block. Take the 0.9 and give it to Exit nodes. There will probably not be a lot of exit nodes compared to service nodes so this smaller amount is a good point to see how exit not incentivisation works.

We don't want service nodes being taken down because of abuse reports so exit nodes should be on a separate server and linked to a service node via a key. This way if an exit node gets taken down then it wouldn't affect the service node rewards.

Also it would be good to have an additional incentive such as running an exit node provides some additional leniency towards the linked service node being decommissioned or deregistered.

[Lucifer1903]

I also like the idea that @necro-nemesis proposed regarding TCP traffic being the only free option.

[necro-nemesis]

SN should only lose the reward of acting as an exit if they are taken down not the whole enchilada. Somehow the SN can't be put at greater risk of losing basic staking and SN rewards if they are going to act as exits.

[KeeJef]

Youtube, Twitch, most popular video websites (When watching) are using TCP, there is some movement towards WebRTC which is UDP based but i don't think its really seen that much adoption yet. Even the connection between a streamer and twitch uses TCP AFIK

[SomethingGettingWrong]

Being an exit node they are taking a risk would it be possible to have a list of sites an operator might not want to exit too? sort of a black list etc. While they might not know what traffic they are exiting...

it would be good to incentivize all nodes to be exit nodes by allowing a editable blacklist.

For example if an exit node didnt want to route porn from the clearnet. then it just wouldnt connect to those ip address's are sites regardless. If a person wanted to look up porn they could then just find a diffrent path etc.

Make it where the service node could just blacklist clearnet sites it doesnt want to exit or even connect too.

I defintiley like the idea of PAID UDP but Free TCPIP liek tor

[neuroscr]

I think paid exit nodes are DOA idea because they won't be able to compete with free exit nodes. If you don't know, any SNAPP can be converted into an exit-like-service and there's nothing lokinet can do about that (unless we prioritized official exit traffic differently than SNAPP traffic and if you did that you start to leak meta data).

if we didn't have an explicit lokinet exit support (and only support it through 3rd party snapps) then we wouldn't have any snodes exposed to the pitfalls of exit duty. A snapp operator could choose to set up a paid or free exit and then we have a truly free market at work here that Loki doesn't have to get involved with. Though after some additional discuss on telegram; this would not offer the sybil-resistance that snode-based-exits can provide.

I like the idea of trying to leverage TOR exits for TCP traffic and Lokinet doesn't need to do anything for that to happen. It maybe bad optics for Loki to do so and also could be used as point of monitoring exit activity but it's not clear to me that Lokinet could ever give the assurance it could prevent eavesdropping in exit-mode.

UDP can be purchased from the node operator.

I don't think this will be preferable when HTTP/3 (which uses UDP) is mainstream.

Also one of the benefits we can build into lokinet is real mutlicast which would be ideal with UDP. This is technology that can't be effectively deployed on clearnet and has real world savings if we can show it working on lokinet (and is freely available to their large audiences).

I was just asked to explain multicasting:

So in streaming, with unicast you have to send your stream bit rate to each of your viewers. So let’s say 100 users at 100kbps, that’s 10mbps on the distribution point’s upload. Multi casting makes it like a radio broadcast, so the distribution points upload is only using 100kbps and can support (almost) infinite users on it It’s can’t happen on clearnet because every router between the source and listeners has to support and have multi casting enabled. So it’s very rare on clearnet to have many users on multicast.

[William-E-Coyote]

I agree with @KeeJef that increasing users is the most important part of moving forward. We need to spread the LOKI brand and Session messenger flagship. Adding an easily accessible decentralized VPN with better security than TOR is a strong proposal. In time we can figure out how to properly incentivize and increase efficiency for the network.

I like the idea of taking the smallest effective step and just ask SN operators to volunteer for exit nodes. Perhaps this could only include TCP traffic. There are so many unknowns with EN that just getting something started may show a better direction. This will give an acceptable live testing platform to test EN and insure the system works before any financial incentives are promised. Also, when EN start to receive rewards, volunteer SN that are running will be paid first and perhaps they could be paid for previous amount of uptime.

I do think that in time we will need a robust strategy to incentivize and increase the efficiency of the network as increased traffic becomes a limiting factor. I wrote a long proposal here: https://github.com/loki-project/loki-improvement-proposals/issues/21

[Lucifer1903]

I'm just going to throw this idea out there so it's known.

Instead of paying the EN block reward directly to ENs they could be given to EN users in the form of non-transferable, expirable vouchers (this could be done on a second blockchain only for vouchers and only go back 24 hours causing the vouchers to expire after 24 hours).

The lokinet client could include a backend wallet where these vouchers are issued. The EN user wouldn't even need to know this is happening in the background.

These vouchers could be spent on EN usage however they would be limited to only being spent on the EN that has had the least amount of vouchers spent on them over the last 24 hours (this would keep the free usage balanced between all Exit nodes while all preventing an operator from pretending to be a user and only spending the vouchers on their own EN).

When the vouchers are spent they are converted to loki and paid to the EN on the main blockchain.

EN users that want to choose which EN they use can pay for the service.

[notlesh]

I believe an open market can mitigate all of these concerns. If an exit node is free to decide how their business model works, they can offer any range of service with any pricing model they wish. This includes all sorts of freemium models:

• Completely free (e.g. Tor)
• Throttled free, paid unthrottled
• Free web-only (port 80 / 443), paid unlimited
• Free X bandwidth-per-month, paid unlimited
• No free, paid fast service
• Free USA-based exit, paid non-USA-based exit
• Free with blacklist

Etc. etc. This open-market approach would allow exit operators to match existing UX models everywhere from Tor (free but often poor UX) to pay-per-bandwidth to subscription-based. Furthermore, competition should sufficiently create incentive to provide various free-tier options to lure customers in. I believe this would provide far superior free-tier availability than an opt-in exit participation model.

It's also worth pointing out that there is benefit in a separation-of-concerns: Service Node operators have a vastly different risk model than exit nodes. Combining the two necessarily combines all of this risk into one basket.

From a technical perspective, it's hard to overstate just how difficult it will be in practice to implement a testing system. Testing Service-Node functionality is difficult enough, where most of what we are testing is within the domain of our own protocol and incentive model. Our internal discussions, while productive, have yet to yield any sort of silver-bullet for this simplified testing.

Compare this to testing Exit Node functionality where almost everything we would want to test is beyond the scope of our protocols. The simple fact is that the internet looks very different across geographic boundaries and time, so it's just not feasible for me to expect someone else to be able to do arbitrary things on the internet and punish them if they fail to do so. If you've played around with Tor's exit functionality much, you've no doubt realized that the vast majority of the internet is suddenly hidden behind aggressive captchas. How can we possibly perform automated tests in such an environment?!

As for onboarding (USD -> Loki, etc.) issues, this is something we can address separately. Others have discussed providing a separate token which could only be redeemed for service, which might allow us to more easily provide an onramp from fiat currency or credit. Also consider that if a free market of Exit Nodes has lured in users from various freemium models, this won't be as much of a barrier to entry.

[majestrate]

something to keep in mind: http/3.0 uses quic which is over UDP, when major players switch over tor exits will not be able to carry that traffic. we on the other hand will.

[necro-nemesis]

Wow. That's not very future-proof for TOR.