Skip to content

Commit

Permalink
BOLT 12: Allow sending amounts in invoice_request even if offer has it.
Browse files Browse the repository at this point in the history
The actual amount can be complicated (x quantity, and proportional for
some recurring offers), but allow the sender to specify it, for
tipping purposes.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
  • Loading branch information
rustyrussell committed Jan 8, 2021
1 parent 781004a commit e02c7d8
Showing 1 changed file with 13 additions and 2 deletions.
15 changes: 13 additions & 2 deletions 12-offer-encoding.md
Original file line number Diff line number Diff line change
Expand Up @@ -550,7 +550,9 @@ The writer of an invoice_request:
- MUST specify `amount`.`msat` in multiples of the minimum lightning-payable unit
(e.g. milli-satoshis for bitcoin) for the first `chains` entry.
- otherwise:
- MUST NOT set `amount`
- MAY omit `amount`.
- if it sets `amount`:
- MUST specify `amount`.`msat` as greater or equal to amount expected by the offer.
- if the offer contained `recurrence`:
- for the initial request:
- MUST use a unique `payer_key`.
Expand Down Expand Up @@ -596,7 +598,6 @@ The reader of an invoice_request:
- otherwise:
- MUST fail the request if there is a `quantity` field.
- if the offer included `amount`:
- MUST fail the request if it contains `amount`.
- MUST calculate the *base invoice amount* using the offer `amount`:
- if offer `currency` is not the invoice currency, convert to the
invoice currency.
Expand Down Expand Up @@ -638,6 +639,10 @@ The reader of an invoice_request:
- otherwise (the offer had no `recurrence`):
- MUST fail the request if there is a `recurrence_counter` field.
- MUST fail the request if there is a `recurrence_signature` field.
- if the offer and request both contain `amount`:
- MUST fail the request if its `amount` is less than the *base invoice amount*.
- MAY fail the request if its `amount` is much greater than the *base invoice amount*.
- SHOULD use the request's `amount` as the *base invoice amount*.

## Rationale

Expand All @@ -659,6 +664,12 @@ BIP-32 derivation path); a valid system might be for a node to maintain a base
payer key, and encode a 128-bit tweak here. The payer_key would be derived by
tweaking the base key with SHA256(payer_base_pubkey || tweak).

Users can give a tip (or otherwise obscure amounts sent) by specifying
an `amount` in their invoice request, even though the offer specifies
an `amount`. Obviously this will only be accepted by the recipient if
the invoice request amount exceeds the amount it's expecting.


# Invoices

Invoices are a request for payment, and when the payment is made they
Expand Down

0 comments on commit e02c7d8

Please sign in to comment.