On 12/2/21 21:59, Rusty Russell wrote:
Matt Corallo <lf-li...@mattcorallo.com> 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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
