ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-03 📝 Original message: Good morning Pierre and ...
📅 Original date posted:2019-04-03
📝 Original message:
Good morning Pierre and list,
> 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.
Just to be clear, the issue is for example with a network like:
A ------- B -------- C
/ \
/ \
/ \
/ \
D ------- E
Then, A creates an inner trampoline onion "E->C", and an outer onion "A->B->E".
E, on receiving the inner trampoline onion "E->C", finds that E->B direction is low capacity, so routes over the outer onion "E->D->B->C" with inner trampoline onion "C".
This creates an overall route A->B->E->D->B->C.
When the B->C HTLC is resolved, B can instead claim the A->B HTLC and just fail the D->B HTLC, thereby removing D and E from the route and claiming their fees, even though they participated in the route.
> (maybe private keys?)
Do you refer to the changing from "H"TLC to "P"TLC point-locked timelocked contracts?
i.e. instead of payment hash / preimage, we use payment point / scalar.
I think a few ideas would be improved by this.
1. Trampoline payments, as described above.
2. Offline vending machines
- Instead of storing a fixed number of invoices from the always-online payment node, store a HD parent point and derive child points for payments.
3. Enables payment decorrelation.
Perhaps we should consider switching to payment points/scalars sometime soon.
Regards,
ZmnSCPxj
Published at
2023-06-09 12:54:46Event JSON
{
"id": "2eb54c388cbcf811f23a04d54834d284408046de3be2146f66e9e9652a3ab16b",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315286,
"kind": 1,
"tags": [
[
"e",
"60d26284fa5c438b86871bb223a7961f45c149bf53b3a176e75fc003d1d27577",
"",
"root"
],
[
"e",
"c22c63cf2392b27b08cef8057ddeab97a3bbefff00cf5bb5c692dfa33fa22a2c",
"",
"reply"
],
[
"p",
"208e7a4699791a0264a0298ffa60456c51ac8d8992096a1b67389965eccc82ff"
]
],
"content": "📅 Original date posted:2019-04-03\n📝 Original message:\nGood morning Pierre and list,\n\n\u003e There is another unrelated issue: because trampoline nodes don't know\n\u003e anything about what happened before they received the onion, they may\n\u003e unintentionnaly create overlapping routes. So we can't simply use the\n\u003e payment_hash as we currently do, we would have to use something a bit\n\u003e more elaborate.\n\nJust to be clear, the issue is for example with a network like:\n\n\n A ------- B -------- C\n / \\\n / \\\n / \\\n / \\\n D ------- E\n\nThen, A creates an inner trampoline onion \"E-\u003eC\", and an outer onion \"A-\u003eB-\u003eE\".\n\nE, on receiving the inner trampoline onion \"E-\u003eC\", finds that E-\u003eB direction is low capacity, so routes over the outer onion \"E-\u003eD-\u003eB-\u003eC\" with inner trampoline onion \"C\".\n\nThis creates an overall route A-\u003eB-\u003eE-\u003eD-\u003eB-\u003eC.\n\nWhen the B-\u003eC HTLC is resolved, B can instead claim the A-\u003eB HTLC and just fail the D-\u003eB HTLC, thereby removing D and E from the route and claiming their fees, even though they participated in the route.\n\n\u003e (maybe private keys?)\n\nDo you refer to the changing from \"H\"TLC to \"P\"TLC point-locked timelocked contracts?\ni.e. instead of payment hash / preimage, we use payment point / scalar.\n\nI think a few ideas would be improved by this.\n\n1. Trampoline payments, as described above.\n2. Offline vending machines\n - Instead of storing a fixed number of invoices from the always-online payment node, store a HD parent point and derive child points for payments.\n3. Enables payment decorrelation.\n\nPerhaps we should consider switching to payment points/scalars sometime soon.\n\nRegards,\nZmnSCPxj",
"sig": "666b299720779ea029ff67c3d4235e0bcb72a9e9e025d0df5b01b4c7526ae60c2cca3a51bdb14d1effc176c9530ffdc742c7b92f1370aba9f31649c3a65dce42"
}