From ZmnSCPxj at protonmail.com Wed Oct 13 09:58:40 2021 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 13 Oct 2021 09:58:40 +0000 Subject: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User... In-Reply-To: <141bf953-1d49-eab5-5151-a7b8d1937b52@mattcorallo.com> References: <141bf953-1d49-eab5-5151-a7b8d1937b52@mattcorallo.com> Message-ID: 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