[Lightning-dev] Routing on the lightning network?

[Nick ODell]

>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 <cjp at ultimatestunts.nl> 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