From cjp at ultimatestunts.nl  Tue Jul 14 18:54:44 2015
From: cjp at ultimatestunts.nl (CJP)
Date: Tue, 14 Jul 2015 20:54:44 +0200
Subject: [Lightning-dev] Routing on the lightning network?
In-Reply-To: <87pp43v6rp.fsf@rustcorp.com.au>
References: <874mlm0z5k.fsf@rustcorp.com.au>
	<1436295968.4352.49.camel@hppg6.kloosterkade>
	<87pp43v6rp.fsf@rustcorp.com.au>
Message-ID: <1436900084.4523.87.camel@hppg6.kloosterkade>


> 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