Trusted offers for tips and payments between friends #12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Oh I'd assumed this was already part of bolt12! Glad you raised it. Totally agree this is extremely valuable. |
rustyrussell
added a commit
that referenced
this pull request
Mar 5, 2023
The specification wasn't fully fleshed out for these, so leave them undefined. We can always re-add them in future. Signed-off-by: Rusty Russell <[email protected]>
rustyrussell
added a commit
that referenced
this pull request
Apr 2, 2023
A BOLT11 "invoice" has proven too low-level for human use in many
scenarios. Efforts like lnurl have covered the gap, but integrating
some of such higher layers into the lightning protocol itself has many
advantages.
This draft defines three new things:
1. A new invoice format. I know, this is painful, but it maps almost
1:1 to the current format (though signatures are very different),
is easier to implement, and easier to send via the lightning
network itself.
2. Formats for an "offer", which for all intents and purposes serves
as the new, persistent invoice for users.
3. Format for an "invoice_request": this is a message sent via the
lightning network itself to receive the real invoice, or can
be used directly in a send-money scenario (e.g. ATM).
Features which have been deliberately omitted for the initial version:
- Recurrence.
- Invoice replacement ("don't accept that old payment!")
- Payer proof for refunds.
I need to thank everyone who gave detailed feedback, particularly:
1. Thomas H of ACINQ (https://github.com/thomash-acinq)
2. Joost Jager (https://github.com/joostjager)
3. Aditya Sharma (https://github.com/adi2011)
4. Rene Pickhardt (https://github.com/renepickhardt)
5. Bastien Teinturier (https://github.com/t-bast)
6. Valentine Wallace of LDK (https://github.com/valentinewallace)
7. Matt Corallo of LDK (https://github.com/BlueMatt)
8. Jeffrey Czyz of Square Crypto (https://github.com/jkczyz)
Also @bjarnemagnussen, @ellemouton, @animatedbarber, @617a7a,
@instagibbs, and @eupn.
Header from folded patch 'invoice-features.ptch':
BOLT 12: clarify that feature spaces are different, define invoice MPP feature.
I was going to reuse features, except BOLT 9 says that `basic_mpp` requires
`payment_secret`, which doesn't make sense for BOLT 12.
So let's define a new feature space for each of offers,
invoice_requests and invoices.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'more-feedback.patch':
fixup! BOLT 12: offers, fifth draft
More clarifications for the sharp-eyed @jkczyz, including changing the
MPP bits in invoices to match bolt 9, for ease.
Others:
1. Remove the (redundant) definition of `blinded_path` from bolt 12,
2. Fix formatting mistake which messed up tools/extract-formats.py.
3. Remove unused `send_invoice` field from invoice.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'invoice_request-less-verbose.patch':
fixup! BOLT 12: offers, fifth draft
invoice_request_x fields turned into invreq_. The names get quite long
otherwise, and that's bad for code (which is clearest if it uses the
same names as the spec, even if it's not directly generated).
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'more-fixes-and-quantity-min-remove.patch':
fixup! BOLT 12: offers, fifth draft
1. Remove offer_quantity_min, use offer_quantity_max=0 to indicate any.
2. Renumber offer_node_id so it's still continuous.
3. Reword "any unknown fields > 80" to "any fields > 80".
4. Fixed MPP inline numbers.
Thanks again to @jkczyz.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'flesh-out-offer-reader-requirements.patch':
fixup! BOLT 12: offers, fifth draft
Make sure every relevant offer field has reader requirements now.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'fixup-again.patch':
fixup! BOLT 12: offers, fifth draft
1. invoice_request of course sets signature fields (which are greater than 160).
2. invoice_request reader requires invreq_metadata field.
3. Rename "base invoice amount" to clearer "expected amount".
4. MAY FAIL if invoice_request amount "greatly exceeds", to allow tips, etc.
5. Describe how invoices should set `invoice_amount`.
6. Remove bogus exclusion of `invreq_amount` from invoice field comparison (from
older draft where it could change).
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'update-merkle-test-vectors.patch':
fixup! BOLT 12: offers, fifth draft
Fix test vectors to match new signature scheme. Now merkle is only used
for the signature, this is really a signature test, so rename the test
vector too.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'more-trivial-quantity-max-fixes.patch':
fixup! BOLT 12: offers, fifth draft
@jkczyz has more useful tweaks for quantity_max.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'unsolicited-invoices.patch':
fixup! BOLT 12: offers, fifth draft
Flesh out the handling of unsolicited (e.g. bolt11-style) invoices.
In particular, it has no invreq_payer_id, but still reuses
offer_description, offer_node_id and invreq_chain.
Requirements for responding to an invoice_requests have been reshuffled,
but not changed.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'not-so-strict-with-disallowed-paths.patch':
fixup! BOLT 12: offers, fifth draft
I think that invoice writers should be able to give us paths with
required features: we don't use them, and obv. reject if there are no
usable paths.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'fixup-ya.patch':
Allow offer_quantity_max to be 1.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'invoice_node_id.patch':
BOLT 12: add explicit invoice_node_id.
This is usually equivalent to offer_node_id, but if there's no offer,
it's used by itself. This simplifies things quite a bit (we always
have a signature in invoices again), and avoids the awkward invoice
code.
In future, we can:
1. Allow delegation (i.e. provide a signature field which shows a delegation
from the offer_node_id to this invoice_node_id).
2. Maybe allow omitting the offer_node_id, using the first blinded path
final hop as an implied offer_node_id.
Signed-off-by: Rusty Russell <[email protected]>
Header from folded patch 'more-fixups.patch':
More tweaks from jkczyz.
Signed-off-by: Rusty Russell <[email protected]>
iff --git a/12-offer-encoding.md b/12-offer-encoding.md
index 8671024..1459098 100644
Header from folded patch 'remove-definition-of-raw-invoices.patch':
BOLT #12: remove definitions around "raw invoices".
The specification wasn't fully fleshed out for these, so leave them
undefined. We can always re-add them in future.
Signed-off-by: Rusty Russell <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today, a common use of mobile wallets is to maintain a list of your friends and send payments to them. This can already be done with the current state of offers but with less than ideal UX: each user must opt-in by creating an amount-less offer with a generic useless description. I suggest allowing the payer to create the offer themselves as long as they know a node id or a blinded route, and because unlike standard offers they do not correspond promise from the recipient, they are marked with
is_trusted.This allows the following scenario:
Alice and Bob go to a pub and order a bear each. Alice pays the whole bill and creates an offer with amount for one beer that she gives to both Bob. Bob pays the offer, giving Alice a blinded route to him in the process. Alice and Bob now both have a way to contact each other and may won't need to scan a QR code again next time they pay the bill.
This may seem like a negligible improvement but not being able to send money to someone you've already paid or received from is a terrible experience compared to what everyone is used to.