📅 Original date posted:2018-11-09
📝 Original message:
Neat! I think this is similar to what has been briefly discussed earlier
about hybrid packet-switched/circuit-switched payment routing.
B doesn't have to care about how the payment gets from C to D, but she
knows it must go through D, keeping privacy intact. This would be exactly
equivalent to how TOR works today I would think.
C must also make sure the detour route stays within the fee limit of course.
Cheers,
Johan
On Fri, Nov 9, 2018 at 7:02 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/813c32fc/attachment.html>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:52:23
in reply to nevent1q…zmr4
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:52:23Event JSON
{
"id": "4b6343e3199fe0c290667032740cb029cb290742f803e403dc4a2e8bdff32156",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315143,
"kind": 1,
"tags": [
[
"e",
"f4b5ffab7a9c96d8928a76b4653d399422785cf29dac19cdb8e24eff6d895c9a",
"",
"root"
],
[
"e",
"756be3806198f5b8f483955e417d03290cfc28c921daa56bc14db46e4cc17012",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-09\n📝 Original message:\nNeat! I think this is similar to what has been briefly discussed earlier\nabout hybrid packet-switched/circuit-switched payment routing.\n\nB doesn't have to care about how the payment gets from C to D, but she\nknows it must go through D, keeping privacy intact. This would be exactly\nequivalent to how TOR works today I would think.\n\nC must also make sure the detour route stays within the fee limit of course.\n\nCheers,\nJohan\n\nOn Fri, Nov 9, 2018 at 7:02 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning list,\n\u003e\n\u003e As was discussed directly in summit, we accept link-lvel payment splitting\n\u003e (scid is not binding), and provisionally accept rendez-vous routing.\n\u003e\n\u003e It strikes me, that even if your node has only a single channel to the\n\u003e next node (c-lightning), it is possible, to still perform link-level\n\u003e payment splitting/re-routing.\n\u003e\n\u003e For instance, consider this below graph:\n\u003e\n\u003e E\u003c---D---\u003eC\u003c---B\n\u003e ^ /\n\u003e | /\n\u003e |L\n\u003e A\n\u003e\n\u003e In the above, B requests a route from B-\u003eC-\u003eD-\u003eE.\n\u003e\n\u003e However, C cannot send to D, since the channel direction is saturated in\n\u003e favor of D.\n\u003e\n\u003e Alternately, C can route to D via A instead. It holds the (encrypted)\n\u003e route from D to E. It can take that sub-route and treat it as a partial\n\u003e route-to-payee under rendez-vous routing, as long as node A supports\n\u003e rendez-vous routing.\n\u003e\n\u003e This can allow re-routing or payment splitting over multiple hops.\n\u003e\n\u003e Even though C does not know the number of remaining hops between D and the\n\u003e destination, its alternative is to earn nothing anyway as its only\n\u003e alternative is to fail the routing. At least with this, there is a chance\n\u003e it can succeed to send the payment to the final destination.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181109/813c32fc/attachment.html\u003e",
"sig": "2a0ab57f8164105685190ac02ba3751d65ac4f0e7d7f1b4a67272f13242541c2a909450b9f10f87ecf7b5c3fc8517f63fc365953bdbce3650ad6b5dc467bab42"
}