From nickodell at gmail.com Wed Jul 15 00:29:10 2015 From: nickodell at gmail.com (Nick ODell) Date: Tue, 14 Jul 2015 18:29:10 -0600 Subject: [Lightning-dev] Routing on the lightning network? In-Reply-To: <1436900084.4523.87.camel@hppg6.kloosterkade> References: <874mlm0z5k.fsf@rustcorp.com.au> <1436295968.4352.49.camel@hppg6.kloosterkade> <87pp43v6rp.fsf@rustcorp.com.au> <1436900084.4523.87.camel@hppg6.kloosterkade> Message-ID: >I like to think of fees in the same way as we pay for Internet access. >Every physical hop in the Internet has related costs, e.g. in placing >the cables and upgrading the cables when new technology becomes >available and when demand grows. What sort of fee would this be? A percentage fee? A per-transaction fee? Both? I can see a compelling case for any of the three. On Tue, Jul 14, 2015 at 12:54 PM, CJP wrote: > >> Fees are a real issue. Without source routing the client is guessing >> how much fees will be, and there'll be a lot of gaming to decide how >> much of the pie to take (take too much, you get none as payment fails to >> route). I think you'll end up asking your provider how you should to >> pay, and that's a pretty horrible model for privacy. >> >> With source routing and onion it's a little better; you can explicitly >> state what each hop gets. Of course, if your route/payment information >> is out of date you lose, too. > > I like to think of fees in the same way as we pay for Internet access. > Every physical hop in the Internet has related costs, e.g. in placing > the cables and upgrading the cables when new technology becomes > available and when demand grows. Yet it doesn't matter for your Internet > bill how many hops your packets make, or which route they follow. Your > ISP will just average out all the costs it has to make on its > interfaces, and present a fraction of that to each customer. At some > points in the middle between providers, there are places where both > sides have an equal interest in maintaining their link, and no fees are > charged. > > One major difference with the Internet is that we already have a > micro-transaction infrastructure in place, which is something the > Internet has never had (until now). This means it is possible to do > instant per-transaction payment of transaction fees. The fact that we > CAN do it doesn't mean we SHOULD, but I think there are advantages: > non-immediate payment models always require some form of trust from at > least one of the sides. Immediate payment of a transaction fee is as > simple as updating the micro-transaction channel with a slightly larger > amount than the to-be-forwarded transaction amount. > > An interesting question is whether nodes will be prepared to forward > payments at a net loss (the to-be-paid fee is higher than the > to-be-received fee); maybe they will, if they can compensate the losses > with higher profits on other transactions. Fee differences could play a > role in routing decisions. > > That brings me to another point: fees could be used as a way to > incentivize people to bring channels back to equilibrium. When a > channel's funds are almost fully assigned to one of its sides, further > payments towards that side become nearly impossible. Increasing fees in > that direction and decreasing fees in the opposite direction should > incentivize people to perform more transactions that bring the channel > back to equilibrium, and to perform less transactions that bring it > further out of equilibrium, or find alternative routes for those > transactions. > > You could even offer negative fees for transactions that bring a channel > back to equilibrium. There could be a market for people making money > from bringing other peoples' channels back to equilibrium. This would > require either to step away from "net neutrality" (so, not the same fee > for every route / destination), or it would require some form of source > routing and explicitly setting the fees of intermediate nodes. > > My "neutral meeting point" routing design, which is effectively a > two-hop source routing, is already good enough: a node in the middle of > the network is advertising that it can benefit from a negative fee, and > it invites people to perform transactions and to share the profit. It > creates two routable addresses (one for the negative-fee interface (A) > and one for all other interfaces (B)). Other people can then perform a > payment-to-self, with payee side routing to A and payer-side routing to > B. Payee-side can then have a larger payment amount than payer-side, as > agreed with the meeting point, to transfer a part of the profit to the > person performing the transaction. > > CJP > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev