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
Published at
2023-06-09 12:54:46Event JSON
{
"id": "c22c63cf2392b27b08cef8057ddeab97a3bbefff00cf5bb5c692dfa33fa22a2c",
"pubkey": "208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff",
"created_at": 1686315286,
"kind": 1,
"tags": [
[
"e",
"60d26284fa5c438b86871bb223a7961f45c149bf53b3a176e75fc003d1d27577",
"",
"root"
],
[
"e",
"5dd19722976b6409e744294d16139f25820b1b09fc2a260c72cba7190728d069",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "đ
Original date posted:2019-04-01\nđ Original message:\nHello ZmnSCPxj,\n\n\u003e Unless we propose to massively change the onion packet construction...?\n\nI'm afraid we would have to make some changes. I imagine we would have\ntwo onions:\n- one for the adjacent hops (this is the onion we are currently using)\n- one for the trampoline hops\n\nThe 'trampoline onion' would be contained in the per-hop payload of\nthe final node of the 'adjacent onion'. So in your example B would:\n1) receive the htlc\n2) see that it is the last hop in the route, and extract the trampoline payload\n3) peel the trampoline onion and see that it should delegate the payment to C\n4) find a route to C and set the trampoline onion as payload for C\n\nI haven't studied PR #593 enough to tell how easy that would be\nachievable though.\n\nThere is another unrelated issue: because trampoline nodes don't know\nanything about what happened before they received the onion, they may\nunintentionnaly create overlapping routes. So we can't simply use the\npayment_hash as we currently do, we would have to use something a bit\nmore elaborate. (maybe private keys?)\n\nCheers,\n\nPierre",
"sig": "9b280b7a2c6b46b23f260441ac13c65e8144e44a7f15d54f5195371b0683af18e5a4afb8100f8901454bb2b30ffdab0d3174b24db8824d64103fc5ea11b85a53"
}