[Feature request, discussion] Uppercase schema in QR-encoded BIP21strings

[harding]

Bitcoin Core 0.19 through 0.21 (at least) uppercases the bech32 address in BIP21 strings so that they will produce less complex QR codes that can sometimes take up less space or be quicker to scan accurately.

However, RFC3986 allows treating URI schemas as case insensitive, so it should be possible to also uppercase the leading BITCOIN (and the separator : is part of the QR code uppercase set). RFC3986 says:

An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

BIP21 agrees:

The scheme component ("bitcoin:") is case-insensitive, and implementations must accept any combination of uppercase and lowercase letters.

One important downside of this approach is that not all wallets currently implement RFC3986 according to specification. See btcpayserver/btcpayserver#2099 for at least one instance of this. It's my hope that the recent attention the BTCPay team was able to bring to this issue will help get any other wallets with this issue to upgrade in the near future, allowing Bitcoin Core and others to use more efficient uppercase schema strings with bech32 addresses.

[pavlenex]

We're investigating the adoption and wallet support of the upper-cased Bech32 and community is reaching out to wallets that aren't supporting the uppercase. You can follow on the progress we've made in this issue.

[harding]

@pavlenex that's awesome, thank you all!

[Sjors]

For address with a label the bitcoin: to BITCOIN: benefit would be quite marginal, and perhaps not worth the risk of incompatibility with some ancient wallet. This might make it (slightly) more difficult to evacuate coins from an ancient wallet to Bitcoin Core.

[harding]

@Sjors I agree the benefit is fairly marginal (without checking specs, I think uppercase vs. alphanumeric saves like 3 bits per character plus up to 22 bits for mode change, so best case savings is like 46 bits = 3*8+22. For BIP21 strings with a P2WPKH address and an amount of 1.00000000 BTC (no label or extension strings), that's a best case efficiency advantage of about 13.5%).

That said, I think interactions with "ancient" wallets are already going to require the user produce a non-default address type:

• For many wallets last updated more than a year or two ago, bech32 isn't supported, so the Bitcoin Core user is going to need to generate a legacy address anyway. We can keep the bitcoin: schema lowercase in that case since we already keep the base58check string case sensitive.

• For any wallet released as of this writing, it won't support paying to the segwit v1+/taproot addresses that are likely to be deployed, so the Bitcoin Core user is going to need to generate an earlier address type in that case as well.

If users with old wallets are going to need to deal with address incompatibilities for other reasons, I think it's ok to risk asking them to deal with backwards incompatibility due to URI parsing problems too.

[Rspigler]

@ChristopherA BCR-2020-005 supports uppercase and lowercase, so should be compliant with RFC3986?

[ChristopherA]

bcr-2020-05 is specifically designed to work with multiple transports, and is not case-significant.

We suggest lowercase for readability, but for use in QRs to take advantage of the QR-native compression, you need all uppercase. Both forms are completely URI compatible. See bcr-2020-003 for more details on meeting the requirements of RFC3986 and other requirements.

/cc @wolfmcnally