Hello ZmnSCPxj, > Unless we propose to massively change the onion packet construction...?
I'm afraid we would have to make some changes. I imagine we would have two onions: - one for the adjacent hops (this is the onion we are currently using) - one for the trampoline hops The 'trampoline onion' would be contained in the per-hop payload of the final node of the 'adjacent onion'. So in your example B would: 1) receive the htlc 2) see that it is the last hop in the route, and extract the trampoline payload 3) peel the trampoline onion and see that it should delegate the payment to C 4) find a route to C and set the trampoline onion as payload for C I haven't studied PR #593 enough to tell how easy that would be achievable though. There is another unrelated issue: because trampoline nodes don't know anything about what happened before they received the onion, they may unintentionnaly create overlapping routes. So we can't simply use the payment_hash as we currently do, we would have to use something a bit more elaborate. (maybe private keys?) Cheers, Pierre _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev