Hi All,
I would like to revisit a topic that has been discussed earlier between ZmnSCPxj and Christian Decker. [1] I think it's important to revisit it, because not only does ZmnSCPxj propose a cool trick, but it can also be used to mitigate certain attacks. (More on that later) ZmnSCPxj wrote: > 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. Christian replied by explaining this is not possible because "with this scheme it is not possible for C to find an ephemeral key that would end up identical to the one that D would require to decrypt the onion correctly." Christian is correct but I think this problem can be solved with a simple change to the setup. Consider the same graph, but now it's not node A that supports rendezvous routing but it is node D. To circumvent the saturated channel D-C, C creates the route C->A->D, where node D supports rendezvous routing. C can create a sub-route from D to E and treat it as a partial route-to-payee under rendezvous routing by using the hop payload found when unwrapping the onion of the original route B->C->D->E . Because every node in a route is able to create the ephemeral key for the next node by tweaking it with its own shared secret, C is also able to create the ephemeral key for D. C passes that ephemeral key into the payload of the rendezvous node D in the alternate route, signaling to D it needs to swap out the key. D, upon unwrapping its onion sees that it needs to swap ephemeral keys, does so, and goes on with the route to E. Under these changed circumstances I don't think Christian's critique still holds, but I'd love to hear your feedback. Now as to why I think this is useful: 1. ZmnSCPxj proposed this as kind of atomic JIT rebalancing. The rebalancing only happens if the payment happens. 2. It can be used to offload HTLC's to another channel, mitigating channel jamming. 3. It can be used to mitigate Balance Disclosure Attacks, because an attacker wouldn't necessarily be sure which channels are used for routing. I think Rusty calls this "sloppy routing". Thanks for your attention, Gijs van Dam [1]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001573.html
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
