minor: close_signature -> closing_signed #12
Merged
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
|
LGTM 👍 |
bitonic-cjp
added a commit
to bitonic-cjp/lightning-rfc
that referenced
this pull request
Mar 8, 2018
rustyrussell
referenced
this pull request
in rustyrussell/lightning-rfc
Dec 4, 2020
It makes sense to have invoices expire before end of payment window if they're in different currencies, so let them use the default paywindow too. And add the reader requirements to match. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
rustyrussell
referenced
this pull request
in rustyrussell/lightning-rfc
Dec 16, 2020
It makes sense to have invoices expire before end of payment window if they're in different currencies, so let them use the default paywindow too. And add the reader requirements to match. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
jkczyz
pushed a commit
to jkczyz/lightning-rfc
that referenced
this pull request
Jul 31, 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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
Header from folded patch 'fixup-ya.patch':
Allow offer_quantity_max to be 1.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
Header from folded patch 'more-fixups.patch':
More tweaks from jkczyz.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 lightning#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 <rusty@rustcorp.com.au>
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.
Fixed inconsistency in naming (see comments of PR #7)