BOLT 12: feature to allow requests of a bolt11 invoice. - #1336
BOLT 12: feature to allow requests of a bolt11 invoice.#1336rustyrussell wants to merge 2 commits into
Conversation
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
70 is taken by lightning#1149 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
| [bolt04-mpp]: 04-onion-routing.md#basic-multi-part-payments | ||
| [bolt04-route-blinding]: 04-onion-routing.md#route-blinding | ||
| [bolt04-attributable-errors]: 04-onion-routing.md | ||
| [bolt12-bolt11-req]: 12-offer-encoding.md#requrements-for-invoice-requests |
There was a problem hiding this comment.
nit:
| [bolt12-bolt11-req]: 12-offer-encoding.md#requrements-for-invoice-requests | |
| [bolt12-bolt11-req]: 12-offer-encoding.md#requirements-for-invoice-requests |
|
|
||
| The requirement to use `offer_paths` if present, ensures a node does not reveal it is the source of an offer if it is asked directly. Similarly, the requirement that the correct path is used for the offer ensures that cannot be made to reveal that it is the same node that created some other offer. | ||
|
|
||
| The `option_bolt11_request` field allows a backwards-compatible mechanism for simple offers, to simplify transition. |
There was a problem hiding this comment.
Looks like we missed the part to bind the bolt11 invoice. For a bolt12 invoice there's a cryptographic binding, but for bolt11 invoice there is no proof that it is coming from the offer? Like the payer cannot prove it corresponds to the exact request or offer version.
| - MUST set `invreq_quantity` less than or equal to `offer_quantity_max`. | ||
| - otherwise: | ||
| - MUST NOT set `invreq_quantity` | ||
| - if `offer_features` contains `option_bolt11_request`: |
There was a problem hiding this comment.
Guess these if-else's are a bit difficult to follow😂
Given that, when the offer has offer_quantity_max, the writer (payer) must set invreq_quantity, and may set invreq_bolt11 when option_bolt11_request is found in the offer_features, the payer is allowed to include these in a single request,
invreq_bolt11invreq_quantity
which will be rejected by the reader. So we need to add a writer rule: if offer_quantity_max is present, the writer MUST NOT set invreq_bolt11.
|
Mh, I do not recall the main reason why this is considered sanity? Could you please help me to understand what the workflow of LNURL is that will require using bolt12 to fetch a bolt11 invoice? |
5 participants
This would allow a bridge to create a LNURL adapter for a BIP353. for simple offers.