Universal invoicing with Bech32

[dr-orlovsky]

Follow-up to devcall

Initial implementation:
https://github.com/LNP-BP/rust-lnpbp/pull/165/files#diff-432ec656a49ce84afd9b35d78927606bf91f5bcdcb736254df3141ed6eb8b1c4

[kristapsk]

Two comments after listening to recording of devcall.

• Having multiple on-chain addresses for same actual recipient might be useful in some cases. Could be like "here is my main address, but here are some more addresses, if you want to split payment". First, it allows to pay complete amount of invoice in multiple on-chain transactions without address reuse (for example, one might have not enough funds at the moment in a single wallet to pay complete amount, so he would send part from one wallet and part from another). Second, maybe might be useful in JoinMarket Tumbler, where you are required to specify multiple end destination addresses for the tumbler run to avoid amount correlation (tumbler is basically a series of random amount coinjoins). Currently user there specifies three or more addresses manually, but maybe could be simple copy / paste or scanned QR code in the future.
• Not sure I understood slide at 27:31. Why is payjoin not possible here with "classical addresses"? Why can't just BIP78 payjoin callback URL and other data be added to invoice as it's currently already done with BIP21 bitcoin payment URIs?

[dr-orlovsky]

@kristapsk thank you for the comments.

Regarding the slide, probably it must be said that it can't be done within BIP-21 itself w/o external protocol. With PSBT you can provide all necessary info as a part of PSBT, which is not possible with the address

[kristapsk]

In practice non-interactive payjoins will not work anyway, as it will allow to spy on receiver's UTXO's without any cost. With BIP78 to get any information about receiver's UTXO's, you need to pay invoice amount, event if you don't proceed with payjoin, so it's not free.

[dr-orlovsky]

Superseded by https://github.com/orgs/LNP-BP/discussions/147