[epic]: BOLT 12 Implementation Roadmap

BOLT 12 is an alternative to BOLT 11 invoices with reusable offers, a two-step negotiation protocol where a payer decodes an offer, requests an invoice via onion messages, and pays the returned invoice through blinded payment paths. This issue tracks the progress towards that functionality. Original issue: https://github.com/lightningnetwork/lnd/issues/5594. I'll edit this issue to track more fine grained steps (the final architecture is still being worked on) and to link to corresponding PRs.

Milestones

• (A) Codec: bolt12 package for messages and data structures (PoC)
  • https://github.com/lightningnetwork/lnd/pull/10789
  • https://github.com/lightningnetwork/lnd/pull/10832
  • https://github.com/lightningnetwork/lnd/pull/10941
  • https://github.com/lightningnetwork/lnd/pull/10958
  • https://github.com/lightningnetwork/lnd/pull/11001
  • https://github.com/lightningnetwork/lnd/pull/11061
  • https://github.com/lightningnetwork/lnd/pull/11146
  • https://github.com/lightningnetwork/lnd/pull/11191
• (B) Receiver side: offer store, invoice request handler
• (C) Sender side: offer decoding, invoice request construction, payment dispatch
• (D) Multi-hop: pathfinding, blinded path builder, handler upgrade
• (E) PayOffer: safe payment dispatch
• (F) RPC parity: BOLT 12 fields on existing invoice/payment RPCs

Design decisions worth knowing

• Stateless invoice settlement for DoS mitigation: the receiver does not store invoices at creation time. A signed envelope in the blinded path carries enough data to reconstruct the invoice when the HTLC arrives, avoiding per-request DB writes.
• Invoice RPC backward compatibility: the change is planned in such a way that Bolt12 invoices integrate into existing invoice RPCs, with additional Bolt12 specific fields. Hold invoices will not be supported initially.