Glossary / Addresses & keys
Base58Check
Also known as Base58.
- Definition
- Base58Check is bitcoin's original text encoding, which turns binary data into a string of 58 easily transcribed characters and appends a four byte checksum to catch typos.
The alphabet drops the four characters people confuse when copying by hand: zero, capital O, capital I, and lowercase l. A four byte checksum, taken from a double SHA-256 of the payload, means a mistyped address is rejected by the wallet rather than sent into the void, with about one chance in 4.29 billion of slipping through. Every address beginning with 1 or 3 is Base58Check.
How it works
Three pieces go into every Base58Check string. A version byte at the front says what kind of data this is, the payload in the middle carries the actual bytes, and four checksum bytes at the end are the first four bytes of SHA-256 applied twice to the version and payload together. The result is then written in base 58 rather than base 16, which shortens it considerably and removes the ambiguous glyphs.
The version byte is what produces the familiar leading characters. Version 0x00 marks a pay-to-public-key-hash address and comes out as a leading 1; version 0x05 marks a pay-to-script-hash address and comes out as a leading 3; version 0x80 marks a private key in Wallet Import Format, giving 5, K or L. Extended keys use a four byte version instead, 0x0488B21E, which is why every xpub starts with those four letters.
Leading zero bytes get special handling, because base conversion would otherwise discard them. Each 0x00 byte at the start of the payload is written as one extra "1" character, which is why some legacy addresses run shorter or longer than their neighbours despite carrying the same amount of data.
Where you see it
Base58Check is everywhere in bitcoin's first decade and nowhere in its newest formats. Legacy addresses, pay-to-script-hash addresses, WIF private keys, and the xprv and xpub extended keys you export from a wallet all use it. Anything beginning with bc1 does not.
Two properties explain both the popularity and the retirement. Transcription safety was the point: the alphabet was designed so that an address read aloud, copied off a screen, or stamped onto a metal plate survives human handling, and the checksum turns the remaining errors into refusals rather than losses. But the encoding is case sensitive, which forces a QR code into byte mode instead of the more compact alphanumeric mode, and it can only tell you that something is wrong, never what or where.
Base58Check vs Bech32
Base58Check detects errors and bech32 corrects for them. Bech32, specified in BIP-173 and adopted for native SegWit addresses in 2017, uses a 32 character alphabet with no upper case at all, so the whole string fits QR alphanumeric mode and scans from a smaller image. Its BCH checksum guarantees detection of up to four wrong characters and can point at which positions are suspect, rather than simply failing.
The successor needed a patch of its own. A length extension weakness in the original bech32 checksum meant certain addresses could gain or lose a final character undetected, so BIP-350 defined bech32m, which changes one constant and is what Taproot addresses beginning with bc1p use. Base58Check remains valid and will keep working indefinitely, but new address types are not being defined in it.