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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
