René Pickhardt [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: Good morning list, in ...
📅 Original date posted:2018-11-16
📝 Original message:
Good morning list,
in Adelaide I had a long conversation with another participant who
complained that slow payments and failing payments are still a major UX
issue for people that try to use the lightning network. While I believe
this is a very valid point and we might want to think heavily about
altering some design decisions after BOLT1.1 in order to mitigate this I
want to make another proposal which could still be an improvement to some
of the problems that we currently have with path finding. This proposal is
basically a standalone thread to my suggestions sketched in Connors PR at
https://github.com/lightningnetwork/lightning-rfc/pull/503 for non strict
forwarding.
I propose to implement a second routing algorithm that works on the
principle of best effort routing / forwarding with the help of local
payment fragmentation or maybe better called local AMP. I understand this
sounds drastic to start with, in particular since it seems that the
destination has to be known but I believe there are ways to still keep up
with privacy.
The core idea is to allow intermediate nodes to fragment an HTLC to
something similar as Base AMP to reach the next hop that was specified in
the onion. This would still allow to forward a payment and allow the next
hop to to continue with the regular onion package.
The idea is if Alice is supposed to forward an HTLC to Bob with a value
smaller than their channel capacity but alice has not enough funds on her
side alice could try to fragment the payment and try to find several paths
(or maybe just one path without splitting) to Bob.
One particular strategy to find such a path would be to share friend of a
friend (FOAF) information.
Alice could look at the nodes that both she and Bob are connected to and
use them as bridge nodes for the payment. In particular she could even ask
Bob how much inbound capacity he has from those nodes. In case Bob would
share this information about the channel balance of mutual friends it could
deterministically be decided if the original HTLC could be forwarded from
Alice to Bob in a fragmented way.
With the autopilot we are trying to create many triangles in the network so
that there is always the chance for friend of a friend nodes which could be
used with this approach.
On the downside the original payer would have to allow a package to be
locally fragmented by including more fees at each hop and also by
increasing the CLTV deltas in each hop (so that an additional hop can be
included and financed).
With the suggestion I made the payer can still select the basic route and
the full route would still be private. The sender however could chose paths
on which a lot of common friends exist for each pair of nodes on the path
(thereby increasing the probability that the local fragmentation of the
payment has a higher likelihood to be successful)
Of course another solution is if we think that local AMP is too complex and
expensive we could still have the two nodes that fail to forward the htlcs
work collaboratively to find a path between them and return this
information about such a (multi) path as a routing suggestion in the error
message so that the adapted onion package could be tried and sent by the
payer.
best regards Rene
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181116/2f799f7e/attachment.html>;
📝 Original message:
Good morning list,
in Adelaide I had a long conversation with another participant who
complained that slow payments and failing payments are still a major UX
issue for people that try to use the lightning network. While I believe
this is a very valid point and we might want to think heavily about
altering some design decisions after BOLT1.1 in order to mitigate this I
want to make another proposal which could still be an improvement to some
of the problems that we currently have with path finding. This proposal is
basically a standalone thread to my suggestions sketched in Connors PR at
https://github.com/lightningnetwork/lightning-rfc/pull/503 for non strict
forwarding.
I propose to implement a second routing algorithm that works on the
principle of best effort routing / forwarding with the help of local
payment fragmentation or maybe better called local AMP. I understand this
sounds drastic to start with, in particular since it seems that the
destination has to be known but I believe there are ways to still keep up
with privacy.
The core idea is to allow intermediate nodes to fragment an HTLC to
something similar as Base AMP to reach the next hop that was specified in
the onion. This would still allow to forward a payment and allow the next
hop to to continue with the regular onion package.
The idea is if Alice is supposed to forward an HTLC to Bob with a value
smaller than their channel capacity but alice has not enough funds on her
side alice could try to fragment the payment and try to find several paths
(or maybe just one path without splitting) to Bob.
One particular strategy to find such a path would be to share friend of a
friend (FOAF) information.
Alice could look at the nodes that both she and Bob are connected to and
use them as bridge nodes for the payment. In particular she could even ask
Bob how much inbound capacity he has from those nodes. In case Bob would
share this information about the channel balance of mutual friends it could
deterministically be decided if the original HTLC could be forwarded from
Alice to Bob in a fragmented way.
With the autopilot we are trying to create many triangles in the network so
that there is always the chance for friend of a friend nodes which could be
used with this approach.
On the downside the original payer would have to allow a package to be
locally fragmented by including more fees at each hop and also by
increasing the CLTV deltas in each hop (so that an additional hop can be
included and financed).
With the suggestion I made the payer can still select the basic route and
the full route would still be private. The sender however could chose paths
on which a lot of common friends exist for each pair of nodes on the path
(thereby increasing the probability that the local fragmentation of the
payment has a higher likelihood to be successful)
Of course another solution is if we think that local AMP is too complex and
expensive we could still have the two nodes that fail to forward the htlcs
work collaboratively to find a path between them and return this
information about such a (multi) path as a routing suggestion in the error
message so that the adapted onion package could be tried and sent by the
payer.
best regards Rene
--
https://www.rene-pickhardt.de
Skype: rene.pickhardt
mobile: +49 (0)176 5762 3618
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181116/2f799f7e/attachment.html>;