base58 bitcoin encoding is considered legacy

[melvincarvalho]

In the spec, the bitcoin base58 encoding comes up a number of times

However, bitcoin itself, considers base58 to be legacy, and has moved to bech32

Adoption is noted here:

https://en.bitcoin.it/wiki/Bech32_adoption

There is quite a bit of online material regarding the rationale for this e.g.

The mixed case in base58 makes it inconvenient to reliably write down, type on mobile keyboards, or read out loud. The double SHA-256 checksum is slow and has no error-detection guarantees. Most of the research on error-detecting codes only applies to character-set sizes that are a prime power, which 58 is not

For future proofing, it would be good if the spec and examples here could align with current implementations, or there will end up being different competing serializations of the same terms

[dlongley]

Note:

The double SHA-256 checksum is slow and has no error-detection guarantees. Most of the research on error-detecting codes only applies to character-set sizes that are a prime power, which 58 is not...

These latter comments only apply to the Base58Check encoding, which is not used here.

[b5]

The IPFS community has a storied history with base58btc, and has been trying to walk back the decision to use base58 since 2018: ipfs/specs#247

One key lesson to take from the IPFS is base58 doesn't work in URI's. considering did:key uses the colon : character in it's spec this isn't a realistic problem, but I agree that it'd be wise to consider switching the spec away from base58btc

[expede]

+1 to base58 has been a pain to work with in practice

That said we have a bunch of b58 keys in the wild. It's easy enough for us to detect these via the multibase prefix. I'd suggest making the spec open to any multibase prefix. If there's a desire to limit it to a single encoding, we've had success with base64URL as our default across various use cases.