Skip to content
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

BOLT12 Offers Tracking Issue #1970

Open
38 of 60 tasks
TheBlueMatt opened this issue Jan 18, 2023 · 6 comments
Open
38 of 60 tasks

BOLT12 Offers Tracking Issue #1970

TheBlueMatt opened this issue Jan 18, 2023 · 6 comments
Assignees

Comments

@TheBlueMatt
Copy link
Collaborator

TheBlueMatt commented Jan 18, 2023

The following tasks are required to implement BOLT 12 Offers in LDK:

The things left for us to ship BOLT12, in an issue so we don't lose track of things:

  • unsolicited invoices
  • struct deserialization fuzzers
  • fuzzers for the builders, if its doable
  • onion message handler for BOLT12 messages
  • Metadata storage in Offers which can be used to check the correctness of invoice requests
  • non-builder offer/invoice_request/invoice constructor for bindings - cc Ability to construct an invoice from bindings #1868
  • Blinded path payment
  • Blinded path receiving
  • Blinded path forwarding (not strictly required but probably required to test the above and we need it eventually)

After we go public, we should also:

  • Support for non-Bitcoin offers (my fault, I thought the sender had to convert, vs passing no amount in the invoice_request)

Anything I'm missing here @jkczyz?

@jkczyz
Copy link
Contributor

jkczyz commented Jan 18, 2023

We also need to do spontaneous/unsolicited invoices, i.e., BOLT11-style invoices not in response to an InvoiceRequest but rather scanned directly by the user. This was a late addition to the spec. lightning/bolts@7b0c0fc

I think we can punt on this for now similar to non-Bitcoin-denominated offers. Or a volunteer can work on it in parallel. It would be similar to Refund in that it will have its own struct (probably named SpontaneousInvoice) and share the underlying TLV streams. Like Refund it has it's own bech32 prefix (lni instead of lnr).

@jkczyz
Copy link
Contributor

jkczyz commented Jan 18, 2023

For bindings, we probably only need non-builder constructors for Offer and Refund as LDK would handle constructing the others. Though it would still be nice to expose them directly if someone wants to use them without a ChannelManager. Just may be a lower priority.

@TheBlueMatt
Copy link
Collaborator Author

Right, like BOLT11 we'll eventually have folks who want to use them, so we definitely need to support it, but it won't be the "common case". I'm not convinced we shouldn't drop the builders and replace them entirely or at least have a simple util method that calls the builder as appropriate, should be pretty trivial if we go the util method route.

@valentinewallace
Copy link
Contributor

We may also eventually want utilities similar to lightning-invoice::utils::create_invoice_from_channelmanager that will automatically supply the payment hash and blinded payment paths

@jkczyz
Copy link
Contributor

jkczyz commented May 10, 2023

FYI, I repurposed this issue to track all work for BOLT 12 Offers. @valentinewallace Could you update the route blinding portion as needed (i.e., split into more tasks and add PRs)?

@TheBlueMatt
Copy link
Collaborator Author

Also on the blinded path flow - #2534 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

No branches or pull requests

3 participants