Revisiting Link-level payment splitting via intermediary rendezvous nodes [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2021-08-10T00:51:01+00:00


Summary:

In the email exchange, the discussion revolves around the creation of a new route from node C to node E that bypasses a congested channel between nodes D and C. The proposed solution involves node C creating a sub-route from D to E, treating it as a partial route-to-payee using rendezvous routing. To signal the need for a key swap, node C passes an ephemeral key into the payload of the rendezvous node D in the alternate route. Upon unwrapping its onion, node D recognizes the need to swap keys and proceeds with the route to node E.However, there is a practical problem regarding time limits. The HTLC (Hashed Time Lock Contract) from node B to node C has a time limit. With JIT (Just-In-Time) rebalancing, there is a risk that the payment may fail at a later point, resulting in node C paying for rebalancing without actually benefiting from it. On the other hand, link-level splitting requires node C to set a larger time limit for the reroute via node A, which puts its own time limit at risk if any on-chain drops occur.The email revisits a previous discussion between ZmnSCPxj and Christian Decker. ZmnSCPxj proposes a trick to mitigate certain attacks and suggests how it could be used to split payments over multiple hops. Initially, Christian explains why this is not possible. However, the author suggests a simple change in the setup where node D supports rendezvous routing instead of node A. In this modified version, node C creates a new route from C to D via A and utilizes the hop payload when unwrapping the original route's onion to signal the need for key swapping at node D.This modification allows for payment splitting over multiple hops. The author believes this approach could be beneficial for atomic JIT rebalancing, offloading HTLCs to another channel, and mitigating Balance Disclosure Attacks. Overall, the email proposes a modified version of rendezvous routing to split payments over multiple hops. By changing the node that supports rendezvous routing from A to D, a sub-route can be created and treated as a partial route-to-payee under rendezvous routing. The author envisions several useful applications for this approach, including atomic JIT rebalancing, offloading HTLCs, and mitigating Balance Disclosure Attacks.


Updated on: 2023-07-31T23:36:05.520485+00:00