Revisiting BIP21

[MattCorallo]

@RubenSomsen

Similarly, an updated BIP21 should address the question of which address has priority when off-chain addresses have their own custom parameters. E.g. if we take bitcoin:[address1]?option2=[address2]&b12=[b12_address] how do you signify that b12_address takes precedence? You could put it before address2 but now you’ve introduced order dependence at the URI level.

Perhaps this is an argument for not making the distinction between on-chain and off-chain addresses, but we’d still need to support the old parameters for backwards compatibility reasons so we’d probably still need to come up with some kind of deterministic order of preference.

I don’t believe the recipient should decide the payment instructions they wish to use. The URI should simply list all the payment instructions the recipient is willing to accept and the sender (who nearly always shoulders the fees) should pick the one they prefer. I don’t se why there should be any distinction between on-chain and off-chain payment instructions.

This doesn’t address the concern of needing to retroactively define keys for the known address types and still requiring new BIPs to define a key to be usable with BIP21.

This is a fair point, however I think we can simply mark them as “existing ones” and leave them in the URI body rather than in query parameters. There are already many implementations that assume they’re there/place them there, and the ship has kinda sailed on changing that. You could make an argument that we should add an option to put taproot/bech32m instructions in the query parameters to let folks offer both Segwit/bech32 and taproot/bech32m instructions in the same URI, but I don’t really see a super compelling use for that, and I think its just too late.

But forgetting the new keys concern for a second, we could define a new generic addr key for BIP21 which is only usable with self-identifying address types (legacy, p2sh, segwit, taproot, any new address with an HRP), or only usable with addresses that have an HRP (bech32, bech32m) since the HRP is functionally equivalent to an extension key. This means existing address types just work and any new address type with an HRP would also just work. We would still need new payment protocols (b12 for example) to define their own extension keys, but this seems strictly better than needing to define keys for legacy, p2sh, bech32, bech32m/tr, bech32m/sp, etc. Sure, the sending client would still need to check each addr option, but this seems trivial. If we defined addr as only allowing addresses with an HRP, its functionally the same since checking for an HRP is the same as checking for an extension key.

I’m not sure what the advantage of addr is over simply reusing the HRP - it just seems less descriptive for no reason. I went ahead and wrote up the concrete set of changes I think make sense at Update BIP 21 with information about more modern usage of it by TheBlueMatt · Pull Request #1555 · bitcoin/bips · GitHub

The more I think about it, this seems like a nice middle ground: update BIP21 to allow anything that already self identifies with an HRP to be included as a parameter. If it doesn’t have an HRP or if the HRP doesn’t indicate the protocol being used (payjoin, for example), it needs an extension key. This would allow URIs of the form:

This doesn’t allow, for example, offering both Silent Payment instructions as well as Lightning.