Good morning Gijs, > 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.
I confess that I only have a very vague understanding of this bit (Christian understands the math involved better than me), but my vague understanding suggests this is correct. However, a practical problem here is that the incoming HTLC B->C has some time limit. Presumably, the payer B allocates every time limit for the individual HTLCs D->E, C->D, and B->C so that the time limit is the minimum advertised by the receiver. Thus, if C decides to route via C->A->D, it has to ask C->A and/or A->D to give a lower time limit, or else risk its own time limit (i.e. its outgoing C->A has a time limit that is too near to the incoming B->C time limit, or even possibly exceed its incoming time limit). Thus: * For JIT rebalancing, the risk is that the payment ends up failing at some later point, and C paid for a rebalance without actually benefiting from it. * For the link-level splitting, the risk is that C has to give a larger time limit for the reroute via A, risking its own time limit if something has to drop onchain. The risks are more extreme with link-level splitting --- it is far less likely to occur (the risk only really happens if things have to drop onchain, but if things remain offchain and everyone just acts in good faith, then nothing bad happens) but the consequences are more dire (C potentially loses the entire payment amount, whereas with JIT rebalancing, C only risks the fee to rebalance). If C has some special assurance with D and/or A that reduces its risk of dropping onchain (maybe some contract or agreement?) then it may be useful to continue this development, as it trades off one kind of risk for another. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
