📅 Original date posted:2021-10-13
📝 Original message:
Good morning Matt,
> 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?
Just that: two hashes instead of one.
Make *every* HTLC on LN use two hashes, even for current "online RPi user pays online RPi user" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway.
>
> If you're gonna adapt every node in the path, you might as well just use PTLC.
Correct, we should just do PTLCs now.
(Basically, my proposal was just a strawman to say "we should just do PTLCs now")
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 13:04:15
in reply to nevent1q…rtqk
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:04:15Event JSON
{
"id": "ec572ad3045debacf9ae01aed26597d583150c3442499bdd6e18da4bbae5156e",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315855,
"kind": 1,
"tags": [
[
"e",
"a45d159e19433c7f6deb510f4e3d721b133919f795d30ba6b0ff4c3a08e6ef97",
"",
"root"
],
[
"e",
"c4f456f63e6a565dfba9cb31695349533e2a99fffdb5facd544d973a16177b20",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2021-10-13\n📝 Original message:\nGood morning Matt,\n\n\u003e On 10/13/21 02:58, ZmnSCPxj wrote:\n\u003e\n\u003e \u003e Good morning Matt,\n\u003e \u003e\n\u003e \u003e \u003e The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to\n\u003e \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 \u003e just go ahead and do this for every PTLC payment, cause why not? Now the sender and the lnurl\n\u003e \u003e \u003e endpoint have to collude to steal the funds, but, like, the sender could always just give the lnurl\n\u003e \u003e \u003e endpoint the money. I'd love suggestions for fixing this short of PTLCs, but its not immediately\n\u003e \u003e \u003e obvious to me that this is possible.\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \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 \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\u003e\n\u003e Yes, you could create a construction which does this, sure, but I'm not sure how you'd do this\n\u003e without informing every hop along the path that this is going on, and adapting each hop to handle\n\u003e this as well. I suppose I should have been more clear with the requirements, or can you clarify\n\u003e somewhat what your proposed construction is?\n\nJust that: two hashes instead of one.\nMake *every* HTLC on LN use two hashes, even for current \"online RPi user pays online RPi user\" --- just use the `payment_secret` for the preimage of the second hash, the sender needs to send it anyway.\n\n\u003e\n\u003e If you're gonna adapt every node in the path, you might as well just use PTLC.\n\nCorrect, we should just do PTLCs now.\n(Basically, my proposal was just a strawman to say \"we should just do PTLCs now\")\n\n\nRegards,\nZmnSCPxj",
"sig": "b67faab4de81e6fcca6be81938f06ea4d37a9b7031b78a34bb3fa4557f5be3efbd2717a13c4671717dd07af81bf909f981a9055c4ac22c9c30d0fc7a6b7b43df"
}