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