Base58
Base58 is a family of binary-to-text encodings that uses 58 alphanumeric symbols. Bitcoin's alphabet is 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz. It omits 0, O, I and lowercase l to reduce visual ambiguity, and it avoids punctuation and whitespace that can be awkward when copied.[1]
Base58 is an encoding, not encryption and not a key-derivation algorithm. Encoding a private key does not calculate its public key, and decoding a Base58 string does not prove that the underlying data is valid for a particular application.
Encoding
The byte sequence is interpreted as a large integer and repeatedly divided by 58; the remainders select symbols from the alphabet. Leading zero bytes require special handling and are represented by leading 1 characters in Bitcoin's form. Decoding reverses this conversion.
Plain Base58 provides no error detection. Bitcoin commonly uses Base58Check, which combines a version byte or other prefix with a payload and appends the first four bytes of a double SHA-256 hash as a checksum before Base58 encoding.[2] The checksum detects many accidental transcription errors, but it is not a digital signature and does not make hostile input trustworthy.
Variants and trade-offs
“Base58” does not identify one universal alphabet. Implementations including Bitcoin's base58btc and Flickr's Base58 use different character orders, so text encoded with one variant must not be decoded under another merely because both use 58 symbols.[3]
Because 58 is not a power of two, Base58 symbols do not align with fixed groups of input bits or bytes. A general encoder therefore performs whole-number base conversion rather than a direct bit grouping such as Base64. This produces compact, punctuation-free identifiers but is less convenient for long binary data and is one reason newer Bitcoin address formats use a base-32 alphabet.[4]
Uses in Bitcoin
Base58Check is used for legacy pay-to-public-key-hash and pay-to-script-hash Bitcoin addresses. It is also used by Wallet Import Format (WIF) for private keys and by BIP 32 for serialized extended public and private keys.[5] Different prefixes distinguish network and data types; software must validate the decoded length and expected prefix rather than relying only on the visible first character.
Bitcoin Core's descriptors document the visible mainnet prefixes 1 for P2PKH and 3 for P2SH; testnet P2PKH can begin with m or n, and testnet P2SH with 2.[6] These are consequences of encoded version bytes, not characters that an application may safely add or remove by hand.
Native SegWit addresses use Bech32 instead of Base58Check. BIP 173 introduced Bech32 for version 0 witness programs and described limitations of Base58, including the cost of mixed-case QR encoding and the absence of a stronger error-detection guarantee.[4] BIP 350 later specified Bech32m for witness versions 1 through 16, while version 0 continues to use Bech32.[7]
Base58 strings are case-sensitive. Changing capitalization, removing a leading 1, or substituting a similar-looking symbol changes the decoded bytes or causes checksum failure. Applications should use a maintained decoder with explicit size and type checks instead of treating every Base58-looking string as an address or key.
See also
References
- ↑ Bitcoin Core, “base58.h”, checked 15 September 2026.
- ↑ Bitcoin Developer Reference, “Transactions: Address Conversion”, checked 15 September 2026.
- ↑ Multiformats, “Multibase table”, checked 15 September 2026.
- ↑ 4.0 4.1 BIP 173: Base32 address format for native v0-16 witness outputs, checked 15 September 2026.
- ↑ BIP 32: Hierarchical Deterministic Wallets, checked 15 September 2026.
- ↑ Bitcoin Core, “Output Script Descriptors”, checked 15 September 2026.
- ↑ BIP 350: Bech32m format for v1+ witness addresses, checked 15 September 2026.