-
Notifications
You must be signed in to change notification settings - Fork 494
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a mechanism for looking up an offer from a user/domain pair #1136
base: master
Are you sure you want to change the base?
Define a mechanism for looking up an offer from a user/domain pair #1136
Conversation
Signed-off-by: Rusty Russell <[email protected]>
It's far easier to validate these on parsing than to hand-validate them elsewhere. I didn't turn `alias` or `error` into this, though they're similar (`alias` can have a nul terminator). Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
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). The offer (for accepting payments) or invoice_request (for sending payments) are usually presented via a QR code or similar, the replies are sent using onion messages. Each copies fields from the prior so it stands alone, to allow statelessness. 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. Signed-off-by: Rusty Russell <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Regenerated bolt12/signature-test.json; for some reason jq reordered a few fields, but it now shows the complete signature.
bolt12/format-string-test.json is now a valid offer.
Signed-off-by: Rusty Russell <[email protected]>
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as each hop requires a 33-byte `point` for the `next_node_id`. Allow using `short_channel_id` instead, which only requires 8 bytes. Still allow for use of `next_node_id` for cases where the blinded path may not involve channel counterparties or for long-lived offers, which may outlive the given channels.
Offers may contain blinded paths to allow for greater recipient privacy. However, they come at a cost of increased QR code size as the introduction node requires a 33-byte `point`. Define a new `sciddir_or_pubkey` fundamental type such that either a point or a reference to one in a `channel_announcement` can be used. This is backwards compatible with `point`. Use this new type for the `blinded_path` subtype's `first_node_id`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering whether a BOLT change is really needed. Can't this be fully covered by lightning/blips#32 instead?
* [`u8`:`name_len`] | ||
* [`name_len*byte`:`name`] | ||
* [`u8`:`domain_len`] | ||
* [`name_len*byte`:`domain`] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit:
* [`name_len*byte`:`domain`] | |
* [`domain_len*byte`:`domain`] |
@@ -824,6 +825,26 @@ sender of the invoice would have to guess how many msat that was, | |||
and could use the `invoice_error` to indicate if the recipient disagreed | |||
with the conversion so the sender can send a new invoice. | |||
|
|||
# Offer Requests | |||
|
|||
`bitcoin:` URIs with a query paraketer key (case-insensitive) of `omlookup` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
paraketer
-> parameter
what is the denial-of-service strategy on the DNS server side. |
Can you clarify your concern a bit here? Who are you worried about DoSing (or DDoSing?) who? |
Based on #798 and working with https://github.com/TheBlueMatt/bips/blob/2024-02-dns-payment-instructions/bip-XXXX.mediawiki and lightning/blips#32 this defines a mechanism for mapping human-readable names to lightning offers. See the bLIP for a more detailed description in how the process works.