Matt Corallo <lf-li...@mattcorallo.com> writes: > 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?
AFAICT we need to do this for decorrelation: each hop has a unique tweak (prob derived from the onion share secret). In bolt12, we have the additional problem for the tipping case: each invoice contains an amount, so you can't preprint amountless invoices. (This plugs a hole in bolt11 for this case, where you get a receipt but no amount!). However, I think the best case is a generic authorization mechanism: 1. The offer contains a fallback node. 2. Fallback either returns you an invoice signed by the node you expect, *or* one signed by itself and an authorization from the node you expect. 3. The authorization might be only for a particular offer, or amount, or have an expiry. *handwave*. This lets the user choose the trust model they want. The fallback node may also provide an onion message notification service when the real node comes back, to avoid polling. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
