CIP5 - Common Bech32 Prefixes

[KtorZ]

draft proposal for CIP-5

[dcoutts]

As I understand it, bech32 has a quite low limit on its maximum size (90 bytes encoded right?), so it will be unsuitable for any of the larger things, such as most of the certificates. Indeed wouldn't it be unsuitable for extended keys too?

[dcoutts]

These ones do not need to be short, since they are not addresses. I think it is very useful for these keys to include a key "role", or key "type", which is not about the cryptography, but about the purpose of the key. This is to detect and prevent accidentally using a key made for one thing for another. For example to avoid using a stake key as a payment key, or a pool key as a payment key etc etc. We do this in the cardano-cli now and it has saved us from operator error many many times already.

I'll add a full list here later.

[SebastienGllmt]

You may want to mention https://github.com/satoshilabs/slips/blob/master/slip-0173.md

[KtorZ]

As I understand it, bech32 has a quite low limit on its maximum size (90 bytes encoded right?), so it will be unsuitable for any of the larger things, such as most of the certificates. Indeed wouldn't it be unsuitable for extended keys too?

@dcoutts this is partially correct. Bech32 embedded error-detection works very well for chain smaller than 90 characters, but it is said to work reasonably well up to 1024 characters. Above 89 characters, the probability of detecting errors becomes a bit smaller, yet remains okay.

[ilap]

I would prefer smaller HRPs like in the SLIP-173 @SebastienGllmt mentioned also, the "addr" common prefix is too general for the users especially when there would be native multi-asset tokens available for Cardano very soon.

Other reason is having less complex QR codes for the native currency and tokens.
Bech32 has 23 chars and 9 numbers, which can be used in HRP too, that would allow a very compact QR code for a hash28 token addresses as that mode can use only the 32-chars as a character set. As and example ca1xxxxxxx as c and a int the bech32 character set.

Also, we need to distinguish between the wallet- and the chain addresses (serialised keys, hash scripts etc on chain as an example). The wallet addresses are just for humans i.e. wallet users etc. for giving some meaning to or just wrap these chain-addresses.
But, as an example a user could choose his/her wallet address' prefix anyway(in a wallet that have that feature), as it won't affect the real on-chain addresses, meaning addr1xxxx or this_is_my1xxxx can refer to the exactly the same address on the chain.

Anyway, see detailed QR examples for different character sets used with bech32

[dcoutts]

Fine to move into draft status. More comments can still be incorporated.

[crptmppt]

good to go as Draft