[Lightning-dev] negative fees for HTLC relay

[Benjamin Mord]

Although lightning and cryptocurrency is new, the idea of a distribution
network created from links with negotiated fees and with limited
unidirectional capacity that can be corrected via rebalancing, is not new.
In fact there are several very large and mature markets around the world
that we can study which illustrate what people have found to work well in
such contexts, and one class of such markets is wholesale electricity
distribution, such as PJM:
http://www.pjm.com/about-pjm/who-we-are.aspx

When Will Yager mentioned FTRs, he was referring to a specific financial
instrument traded on the PJM, for the purpose of managing load on
transmission lines. Much as with lightning payment channels, power flows in
one direction on a line can be canceled with power flows in the opposite
direction, and so FTR prices are therefore allowed to go negative on the
PJM exchanges for the same reasons as discussed in this thread. If this has
worked for them for some decades, I'm not sure why it wouldn't work for us
also.

In full disclosure, I should point out that this is not the same thing as
electricity transmission. Although they do have counterflow cancellation in
common, payment channel balance is still more analogous to energy than
power, whereas transmission capacity limits are in power and not energy.
Time scales are long enough for manual intervention in PJM negotiations,
whereas timescales necessitate a high degree of automation in lightning
negotiation, as another difference. And there are other differences, and
some might matter.

At at a technical level, I see no complexity at all in allowing fees to go
negative. What is hard about allowing signed versus unsigned integers in
the protocol, and even passing them along? Perhaps there is complexity in a
routing algorithm which attempts to take full advantage of negative fees,
and so perhaps implementations will prefer in the near term to pretend
negative fees are actually zero - but such implementations can easily pass
along info about negative fees even when they themselves choose not to
fully avail themselves of the resulting opportunities. (At worst, some
recipients might receive an unexpected tip! There are worse fates in life.)

As relates to lightning's design goals, I applaud simplifying assumptions
in the early implementations, as a matter of triage - but I would still
discourage premature neutering of underlying protocol expressiveness, since
the resulting limitations can then linger or even come to motivate harmful
or risky forks down the road. Passingly along signed instead of unsigned
ints is easy enough, and we can just cast to unsigned internally, wherever
that may be our local preference.

Incidentally, if anyone is interested in exploring specific application of
lightning to the electricity markets, please contact me offline at
ben at mord.io, as it happens I am attempting to organize such an effort.
While I see opportunity here for collaborative and complimentary work that
could in turn boost lightning adoption, I want to be careful also not to
distract the lightning project from its already ambitious and laudable
mission. Lightning must beware scope creep of a harmful sort, and I'll try
to be disciplined in not encouraging it. We should still walk before we run.


On Thu, Jan 18, 2018 at 12:17 PM, Christian Decker <
decker.christian at gmail.com> wrote:

> Mark Friedenbach <mark at friedenbach.org> writes:
>
> > It is not the case that all instances where you might have negative
> > fees would have loops.
>
> If we don't have a cycle we can hardly talk about rebalancing
> channels. At that point you're paying for someone else's payment to go
> through your channel, and I'm unclear what the motivation for that might
> be. Anyway, this is still possible by communicating this out of band
> with the payment creator, and should not be baked into the gossip
> protocol itself, in my opinion. It's obscure enough to not be worth the
> extra effort.
>
> > One instance where you want this feature is when the network becomes
> > too weighted in one side of the graph.
>
> There is little you can do to prevent this: if we have a network with a
> small cut, with a source and sink on opposite sides of that cut, no
> amount of voluntary sacrifice from the nodes along the cut will have a
> lasting effect. The better solution would be to change the topology of
> the network to remove the cut, or balance traffic over it, e.g., moving
> a sink to the other side of the cut.
>
> > Another is when the other side is a non-routable endpoint. In both
> > cases would be useful to signal to others that you were willing to pay
> > to rebalance, and this hand wavy argument about loops doesn’t seem to
> > apply.
>
> I'm not sure I understand what you mean with non-routable endpoint, so
> correct me if I'm wrong. I'm assuming that non-routable endpoint is a
> non-publicly announced node in the network? In that case no fee tricks
> will ever get people to route over it, since they can't even construct
> the onion to talk to it. Notice that the payment requests allow for
> recipients of payments to get paid by explicitly including the necessary
> information to construct the onion to talk to that node.
>
> Not trying to be dismissive here, and I might be getting this wrong, so
> let me know if I did and what use-cases you had in mind :-)
>
> Cheers,
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180118/e66006d8/attachment.html>