Skip to content

BOLT12 Offers Tracking Issue #1970

Open

Description

@TheBlueMatt

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?

Activity

  1. jkczyz commented on Jan 18, 2023

    @jkczyz
    Contributor

    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).

  2. jkczyz commented on Jan 18, 2023

    @jkczyz
    Contributor

    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.

  3. TheBlueMatt commented on Jan 19, 2023

    @TheBlueMatt
    CollaboratorAuthor

    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.

  4. valentinewallace commented on Jan 21, 2023

    @valentinewallace
    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

  5. jkczyz commented on May 10, 2023

    @jkczyz
    Contributor

    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)?

  6. changed the title [-]BOLT12 TODO List[/-] [+]BOLT12 Offers Tasks[/+] on May 10, 2023
  7. changed the title [-]BOLT12 Offers Tasks[/-] [+]BOLT12 Offers Tracking Issue[/+] on May 10, 2023
  8. moved this to In Progress in LDK Prioritieson May 11, 2023
  9. TheBlueMatt commented on Sep 18, 2023

    @TheBlueMatt
    CollaboratorAuthor

    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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions