BOLT12 Offers Tracking Issue

[TheBlueMatt]

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

• [x] Data abstractions
  • [x] Offer encoding and building #1719, #1972
  • [x] Bech32 encoding and parsing #1726
  • [x] InvoiceRequest encoding, parsing, and building #1738
  • [x] Signature calculation and verification #1738
  • [x] Refund encoding, parsing, and building #1908, #1972
  • [x] Invoice encoding, parsing, and building #1926, #1927, #2162, #2206
  • [x] Test vectors #2334
  • [x] Fuzz testing #1977
• [ ] Onion messages
  • [x] Sending, forwarding, and receiving #1503, #1652, #1650
  • [x] Onion message handling #1688
  • [x] Custom onion messages #1748
  • [x] Onion message router trait #2294
  • [ ] Onion message pathfinding #1724
  • [x] Onion message replies #1652, #2294
  • [x] Fuzz testing #1648, #2686
• [ ] Route blinding
  • [ ] Spec test vectors #3204
  • [x] OM BlindedPath construction #1503
  • [x] Payment BlindedPath construction #2412, #2514
    • [ ] Follow up with custom TLV support for blinded paths #2975, #2830
    • [x] Follow up by setting each hop's PaymentConstraint::htlc_minimum_msat to the max min_htlc for the other nodes in its anonymity set (e.g. for a blinded route A>B>C, set B's min_htlc to the max min_htlc for A's peers)
  • [x] BlindedRoute pathfinding #2146, #2239, #2258, #2305, #2120
    • [ ] Score blinded paths that we've received over so we improve blinded path selection
    • [ ] Support blinded pathfinding to paths where we are the intro node (to be done as a follow-up to offers support)
    • [x] Track failed blinded paths in PaymentParameters similar to the existing previously_failed_channels field: #2818
  • [x] Fuzz test blinded pathfinding #2366
  • [ ] BlindedRoute payments
    • [x] Split onion payload abstraction into forwarding vs receiving #2128
    • [x] Address follow-up from #2128: #2801
    • [x] Sending and receiving to 1-hop blinded paths #2411, #2413, #2576
    • [x] Forwarding and receiving to multi-hop blinded paths #2540, #2688, #2791, #2812, #2823
    • [x] Allowing paying to blinded paths where we are the intro node #3132
    • [ ] Add a random delay before returning any errors if we are the intro node (SHOULD in the spec)
    • [x] Address follow-up from #2540: https://github.com/lightningdevkit/rust-lightning/pull/2540#pullrequestreview-1754409841, https://github.com/lightningdevkit/rust-lightning/pull/2540#discussion_r1408726078
  • [ ] Support probing blinded PaymentParameters (i.e. strip the blinded path off before sending the probe)
  • [ ] Support receiving to blinded paths with phantom
• [ ] Offers message flow
  • [x] Stateless message verification #1989
  • [x] InvoiceRequest and Invoice message handling interface #2294
  • [X] ChannelManager implementation of message handling #2468, #2371, #2039
  • [X] Stateless Offer and Refund builder utilities #2578
  • [x] Multi-hop blinded paths in Offer and Refund messages #2690
  • [x] Multi-hop blinded paths in InvoiceRequest onion message reply paths #2690
  • [x] Multi-hop blinded payment paths in Bolt12Invoice messages #2690
  • [ ] Three-hop blinded paths #2793
  • [ ] Blinded path choice API (i.e. number of paths, number of hops, compact or not)
  • [ ] Correlate InvoiceError with outbound payment using reply paths #2837
  • [ ] InvoiceRequest retries #2836
  • [ ] Fuzz testing
• [ ] Miscellaneous
  • [x] Builder support in language bindings #2903
  • [ ] Non-BTC currencies in Offer
  • [ ] Proof of payment
  • [ ] Authenticate messages using path_id #3139
  • [ ] Full phantom node support
  • [x] Integration testing #2697
  • [x] Update test vectors #2682
  • [x] Compact blinded paths (i.e., using short channel ids) #2921

~~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 #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]

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. https://github.com/lightning/bolts/pull/798/commits/7b0c0fc2b846ec30a2a729d733f4880599734269

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]

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]

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]

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]

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]

Also on the blinded path flow - https://github.com/lightningdevkit/rust-lightning/pull/2534#discussion_r1328985888