📅 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>;
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:52:23
in reply to nevent1q…pr96
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:52:23Event JSON
{
"id": "756be3806198f5b8f483955e417d03290cfc28c921daa56bc14db46e4cc17012",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315143,
"kind": 1,
"tags": [
[
"e",
"f4b5ffab7a9c96d8928a76b4653d399422785cf29dac19cdb8e24eff6d895c9a",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-11-09\n📝 Original message:\nGood morning list,\n\nAs was discussed directly in summit, we accept link-lvel payment splitting (scid is not binding), and provisionally accept rendez-vous routing.\n\nIt 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.\n\nFor instance, consider this below graph:\n\n E\u003c---D---\u003eC\u003c---B\n ^ /\n | /\n |L\n A\n\nIn the above, B requests a route from B-\u003eC-\u003eD-\u003eE.\n\nHowever, C cannot send to D, since the channel direction is saturated in favor of D.\n\nAlternately, 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.\n\nThis can allow re-routing or payment splitting over multiple hops.\n\nEven 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.\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/46387652/attachment-0001.html\u003e",
"sig": "958508b47aae283897cfc311dab316ce534cc96bf77f9e75b94dab86ce35d41ef1f05e89c9a754adc224094042c0b9ef2565d3c83234e073c94ec796d8e778e8"
}