feat: bolt12 (WIP)

[rolznz]

Supports:

• Paying amountless Bolt12 offers
• Receiving Bolt12 payments in transaction list

TODO:

• Decode offer (frontend - needed to check if the offer is amountless or not)
• Pay Bolt12 offers with a set amount
• Make an amountless offer - receive screen could have options: [Lightning address | Invoice | Bolt12 (beta)]?
• NWC planning - pay_offer and make_offer?
• Review metadata
  • When paying data can now be passed in? (New!) - max is currently 512 chars, and then is truncated! https://docs.rs/lightning/latest/lightning/offers/invoice_request/constant.PAYER_NOTE_LIMIT.html
  • How large a description can be stored on an offer?
• Questions for LDK
  • How do I get an offer from an offer ID?
  • How do I get the payer message in a payment received event? - they are working on a PR

TBC:

• Offer decoding (Go)
• Offer storage in transaction table

Notes:

• no way to create offers in the UI - an offer is created on LDK node startup
• no online BOLT12 decoder interface? - can use our CLN instance (lightning-cli decode offer-here)
• variable vs non-variable amounts - only variable is supported
• no BOLT12 decoder on frontend
• our CLN does not have offers support so Bolt12 routing does not work. I think this means also all LND nodes will not route it because they don't handle the onion messages?, and a lot of payments will not work
• offer creation fails if your node doesn't have a channel partner with a peer that has at least 3 channels and at least one public. I think this will be fixed in the next LDK version.
  • offers are based on the channels you have at the time of creation. So if you open new channels, your old offer probably won't work... so people can't save offers to their address list. They still need to save a lightning address (or BIP 353 address)
• offers can include a payer message. This is cool (but it's limited to just a message?).

Dev setup:

2 paired nodes with one node that has at least 3 channels, one of which is public (I think.) See #308