📅 Original date posted:2021-10-13
📝 Original message:
Good morning Matt,
> The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to
> the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we
> just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl
> endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl
> endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately
> obvious to me that this is possible.
Use two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.
You might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).
In addition, I suspect (but have not worked out yet) that this would allow some kind of Barrier Escrow-like mechanism while still in HTLC-land.
Otherwise, just PTLC, man, everyone wants PTLC.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:04:14
in reply to nevent1q…qrdu
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:04:14Event JSON
{
"id": "dd5d39ef4e846492d2bc0deeec499d706ff816400725e7011ff69e34258724d5",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315854,
"kind": 1,
"tags": [
[
"e",
"a45d159e19433c7f6deb510f4e3d721b133919f795d30ba6b0ff4c3a08e6ef97",
"",
"root"
],
[
"e",
"22eef2ec5f37ac91dcad22026675e62895b8a419b868d85b3778b91db7b2b643",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2021-10-13\n📝 Original message:\nGood morning Matt,\n\n\n\u003e The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to\n\u003e the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we\n\u003e just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl\n\u003e endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl\n\u003e endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately\n\u003e obvious to me that this is possible.\n\nUse two hashes in an HTLC instead of one, where the second hash is from a preimage the sender generates, and which the sender sends (encrypted via onion) to the receiver.\nYou might want to do this anyway in HTLC-land, consider that we have a `payment_secret` in invoices, the second hash could replace that, and provide similar protection to what `payment_secret` provides (i.e. resistance against forwarding nodes probing; the information in both cases is private to the ultimate sender and ultimate reeceiver).\n\nIn addition, I suspect (but have not worked out yet) that this would allow some kind of Barrier Escrow-like mechanism while still in HTLC-land.\n\nOtherwise, just PTLC, man, everyone wants PTLC.\n\nRegards,\nZmnSCPxj",
"sig": "5610afc7f79a7e2e1fb33fb9f9f719e36bcf7f4d1392344a5bc1979de9f186210e8b260eb775684efb14217653b4da7d29085373c12b02abe2a2951f6c3980be"
}