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