Updates to invoicing

[dr-orlovsky]

The existing universal invoicing needs several major improvements.

1. It become apparent that the use of Bech32m encoding was a mistake. You can read more about this in here:
   https://github.com/UBIDECO/rust-baid58/blob/0d9f2b2af90212212b0e9ca5723788bf07b5607b/README.md?plain=1#L72-L94
   Additionally to what is said there, Bech32(m) simply doesn't work for anything longer than 90 encoded characters: it is a clearly stated in the BIP-173:

   A Bech32 string is at most 90 characters long

   The reason for the length limit is the fact that the error correction can't handle longer strings; and 6 character checksum appended to the end of the Bech32(m) string is just a waste of space in this case - plus "safety" guarantees of the Bech32 are broken.

   Thus, use of Bech32(m) in lightning invoices was a technical nonsense, also reducing QR code performance.

2. Invoices of different kind would really vary in size by the orders of magnitude - thus, it is a poor design to encode them in the same way. For instance, address-based invoices has size of an bitcoin address; RGB onchain invoices are at least twice of that; RGB lightning invoices are triple or quadriple of that; descriptor based invoices would have length which 10-50 times exceeds size of a bitcoin address, and PSBTs would get to 100-500 of that.

3. Use of miniscript descriptors makes it really hard to support wallets which can't be represented as a miniscript descriptor (for instance, most of pre-Taproot wallets with time-locks and multisigs, or custom wallets created before miniscript was introduced).

4. Existing universal invoices carry no visually parsable information, which is undesirable.

URL support

After a lot of considerations I start to think that providing an invoice in form of an URL is more important than having a single-click-selectable string in some of form of binary-to-text encoding. The only advantage of the latter is "ability to select and copy with a single click", but this doesn't actually adds usability: a user has to perform five (!) manual operations: single-click to select, click copy, going to wallet app, initiating payment, pasting. At the same time, all mobile apps, messengers, browsers, desktop apps etc support URLs, which open into a proper screen (pre-filled with the data from the URL) of a user-configured default wallet app with just one operation: click on a URL. Also, URL has a plenty of advantages over binary strings:

• It is human readable, also human-checkable;
• it clearly distinguish communication protocol, allowing use of different apps for different invoice formats (like storm-supporting wallet for storm invoices, bitcoin wallet for bitcoin, lightning for lightning etc);
• it is much more standard and understandable by people from outside of walled bitcoin garden;
• it doesn't require TLV providing the same parameter flexibility as we have with TLV;
• it is simple to implement in different languages, without a need to run TLV parsers;
• it is able to support long data (like required for PSBT and descriptors) which now may become a part received through an interactive protocol;
• it works much better with QR code parsers and mobile OSes (for bech32 QR codes you can't open a wallet app right from the camera).

Proposal

1. Separate the actual invoice information from the information about payment means. I.e. things like asset name, amount, information about repeated payments etc is the invoice; the rest - like address to pay to, servers, nodes, wallet descriptor, PSBT etc is the information which adds most of the size to the invoice - and usually has its own distinct encodings.
2. Use single standard encoding for the actual invoicing info - and existing standard encodings for the payment means
3. Define a way how the two-part invoices may be transferred via standard communication channels. For instance, for short forms of payment info (bitcoin address or blind RGB utxo) define URL form; for longer (descriptor and PSBT-based) - propose HTTP REST API.

Examples

The resulting desired form of an invoicing protocol should look like:

• bitcoin address-based payment (BIP-20 compatible, with checksum): bitcoin:bc1qxlcvg7ap7ld990f4dv6x09v0dcktvhv2az9cxu?amount=5&recurrent=7EnUZg#invoice-check-words
• RGB on-chain payment:
  • rgb-rpc://wallet.com?asset=asset_check_words_7EnUZgFtu28sWqqH3womkTopXCkgAGsCLvLnYvNcPLRt&amount=395&recurrent=7EnUZg&txob=NopdF52RXruPXgJpGEBik9ki#invoice-check-words
  • rgb+https://wallet.com/asset_check_words_7EnUZgFtu28sWqqH3womkTopXCkgAGsCLvLnYvNcPLRt/NopdF52RXruPXgJpGEBik9ki#invoice-check-words (interactive REST protocol)
  • rgb+wss://wallet.com/asset_check_words_7EnUZgFtu28sWqqH3womkTopXCkgAGsCLvLnYvNcPLRt/NopdF52RXruPXgJpGEBik9ki#invoice-check-words (interactive websockets protocol)
  • rgb+storm://node_check_words_DFpCegE8EESBvYD6NcbnnhTx6NKDFpCegE8QkQd8M@ihqqffiq2x4gxnwv26qq3znk7hb646lw7kaue5iihxf4zunremoainid.onion/asset_check_words_7EnUZgFtu28sWqqH3womkTopXCkgAGsCLvLnYvNcPLRt/NopdF52RXruPXgJpGEBik9ki.txob/?amount=395&recurrent=7EnUZg#invoice-check-words
• bitcoin descriptor or psbt payment with an interactive protocol: bitcoin://wallet.com/NopdF52RXruPXgJpGEBik9ki?amount=45#invoice-check-words
• lightning bitcoin payment: bolt:lnbc15u1p3xnhl2pp5jptserfk3zk4qy42tlucycrfwxhydvlemu9pqr93tuzlv9cc7g3sdqsvfhkcap3xyhx7un8cqzpgxqzjcsp5f8c52y2stc300gl6s4xswtjpc37hrnnr3c9wvtgjfuvqmpm35evq9qyyssqy4lgd8tj637qcjp05rdpxxykjenthxftej7a2zzmwrmrl70fyj9hvj0rewhzj7jfyuwkwcg9g2jpwtk3wkjtwnkdks84hsnu8xps5vsq4gj5hs
• lightning rgb payment: bifrost://node_check_words_DFpCegE8EESBvYD6NcbnnhTx6NKDFpCegE8QkQd8M/asset_check_words_7EnUZgFtu28sWqqH3womkTopXCkgAGsCLvLnYvNcPLRt/KDFpCennhTx6NQd8MgE8QkDFpCegE8EESBvYD6Ncb?amount=584#invoice-check-words

[kristapsk]

Are you aware of unified QRs for Bitcoin? Doesn't have a BIP, but has some wallet support, also supported by BTCPay Server. It is BIP21 based approach, where BOLT11 invoice is added as lightning parameter. So has support from legacy onchain wallets by default. Also can be combined with BIP78 payjoins in the same URI. So such URI can encode four possible methods of payment (simple onchain tx, BIP78 payjoin onchain tx, simple Lightning payment, opening a new channel and then doing Lightning payment).