Pierre [ARCHIVE] on Nostr: š Original date posted:2019-04-01 š Original message: Hello ZmnSCPxj, > Unless ...
š
Original date posted:2019-04-01
š Original message:
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
š Original message:
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