From lf-lists at mattcorallo.com Mon Dec 27 19:12:10 2021 From: lf-lists at mattcorallo.com (Matt Corallo) Date: Mon, 27 Dec 2021 14:12:10 -0500 Subject: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User... In-Reply-To: <874k7qpf4z.fsf@rustcorp.com.au> References: <141bf953-1d49-eab5-5151-a7b8d1937b52@mattcorallo.com> <874k7qpf4z.fsf@rustcorp.com.au> Message-ID: On 12/2/21 21:59, Rusty Russell wrote: > Matt Corallo writes: > 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. Missed this mail, but, right, good point about amounts. Indeed, having cross-signing by the fallback node seems like a good idea. For the tipping use-case, allowing a BOLT-12 response with no amount included under the signature seems fine (with a signed amount from the fallback node). Matt