ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-09 📝 Original message: Good morning list, As was ...
📅 Original date posted:2018-11-09
📝 Original message:
Good morning list,
As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.
It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing.
For instance, consider this below graph:
E<---D--->C<---B
^ /
| /
|L
A
In the above, B requests a route from B->C->D->E.
However, C cannot send to D, since the channel direction is saturated in favor of D.
Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing.
This can allow re-routing or payment splitting over multiple hops.
Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/46387652/attachment-0001.html>;
📝 Original message:
Good morning list,
As was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.
It strikes me, that even if your node has only a single channel to the next node (c-lightning), it is possible, to still perform link-level payment splitting/re-routing.
For instance, consider this below graph:
E<---D--->C<---B
^ /
| /
|L
A
In the above, B requests a route from B->C->D->E.
However, C cannot send to D, since the channel direction is saturated in favor of D.
Alternately, C can route to D via A instead. It holds the (encrypted) route from D to E. It can take that sub-route and treat it as a partial route-to-payee under rendez-vous routing, as long as node A supports rendez-vous routing.
This can allow re-routing or payment splitting over multiple hops.
Even though C does not know the number of remaining hops between D and the destination, its alternative is to earn nothing anyway as its only alternative is to fail the routing. At least with this, there is a chance it can succeed to send the payment to the final destination.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/46387652/attachment-0001.html>;