📅 Original date posted:2021-10-13
📝 Original message:
On 10/13/21 02:58, ZmnSCPxj wrote:
> 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).
Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this
without informing every hop along the path that this is going on, and adapting each hop to handle
this as well. I suppose I should have been more clear with the requirements, or can you clarify
somewhat what your proposed construction is?
If you're gonna adapt every node in the path, you might as well just use PTLC.
Matt
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 13:04:14
in reply to nevent1q…hmv9
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 13:04:14Event JSON
{
"id": "c4f456f63e6a565dfba9cb31695349533e2a99fffdb5facd544d973a16177b20",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315854,
"kind": 1,
"tags": [
[
"e",
"a45d159e19433c7f6deb510f4e3d721b133919f795d30ba6b0ff4c3a08e6ef97",
"",
"root"
],
[
"e",
"dd5d39ef4e846492d2bc0deeec499d706ff816400725e7011ff69e34258724d5",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-10-13\n📝 Original message:\nOn 10/13/21 02:58, ZmnSCPxj wrote:\n\u003e Good morning Matt,\n\u003e \n\u003e \n\u003e\u003e The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to\n\u003e\u003e the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we\n\u003e\u003e just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl\n\u003e\u003e endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl\n\u003e\u003e endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately\n\u003e\u003e obvious to me that this is possible.\n\u003e \n\u003e 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.\n\u003e 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).\n\nYes, you could create a construction which does this, sure, but I'm not sure how you'd do this \nwithout informing every hop along the path that this is going on, and adapting each hop to handle \nthis as well. I suppose I should have been more clear with the requirements, or can you clarify \nsomewhat what your proposed construction is?\n\nIf you're gonna adapt every node in the path, you might as well just use PTLC.\n\nMatt",
"sig": "6ec584024d26978c1287bc723e40d99074d1d2f2e990b55e5c46a246ee8d4dc76654124e7e0d1c6d265c2eaa20d338aa57cd272e2943ebae35e907f110c31a05"
}