ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-13 📝 Original message: Good morning Matt, > The ...
📅 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
📝 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