Can we completely drop the BIP21 `req-` parameter prefix?

[bitjson]

The BIP21 req- parameter prefix was rarely (if ever?) even implemented by wallets. I left it in the 0.1.0 draft because I'm not certain if I've thought through the issue enough, but I don't have a vision of any likely future uses for it. Most new use cases are going to either:

1. Want backwards compatibility, e.g. a p parameter than initiates a P2P connection of some sort, but the URI still has an r for older clients to fall back to, or
2. Be a completely new concept or protocol, where either a new protocol scheme (e.g. lightning:) or new CashAddress version(s) (e.g. CashTokens) are likely to be allocated.

In either case, prefixing a new parameter with req- will be seen as a waste – you either want a short/one-character parameter name, or you want to avoid a new parameter entirely (the address itself embeds the new information).

I'll probably send a PR to drop the idea completely unless someone can offer reasoning to keep it.

[jonas-lundqvist]

I agree, IMHO we should drop it.

The whole premise of the req- prefix was that every wallet implements it such that one can reliably use it and know that transactions do what you need them to do. I have high doubts it will be implemented with the release of this CHIP when it gained close to zero traction with BIP-21.

It was a good idea though…

[bitjson]

Thanks for the comment @jonas-lundqvist. I still haven't come up with a viable use case, and I think our reasoning against including it is quite solid. Dropped in cd4b6fb. 👍