Checksum

What Is a Checksum?

A checksum is a short value derived from a block of data, used to verify that the data has not been altered or corrupted. Think of it like a check digit on a credit card number or an ISBN: the final digits are computed from the preceding ones, so any transcription error will produce a mismatch and be caught before the number is processed.

In Bitcoin, checksums protect addresses, private keys, seed phrases, and peer-to-peer network messages from accidental corruption. When you copy a Bitcoin address and paste it into your wallet, the wallet verifies the checksum before constructing a transaction. If the checksum does not match, the wallet refuses to send, preventing funds from being lost to an address nobody controls.

Checksums are not encryption and they are not signatures. They do not hide data or prove identity. Their sole purpose is error detection: catching mistakes introduced by humans typing, copying, or transmitting data.

How It Works

Bitcoin employs different checksum algorithms depending on the encoding format. The two primary schemes are Base58Check for legacy formats and BCH codes for modern Bech32 formats.

Base58Check (Legacy Addresses)

Base58Check encoding is used for legacy P2PKH addresses (starting with "1"), P2SH addresses (starting with "3"), private keys in WIF format, and HD wallet extended keys. The process works as follows:

1. Prepend a version byte to the payload (0x00 for mainnet P2PKH, 0x05 for P2SH)
2. Compute the double SHA-256 hash of the versioned payload
3. Take the first 4 bytes of the resulting 32-byte hash as the checksum
4. Append those 4 bytes to the versioned payload
5. Encode everything in Base58, a character set that omits visually ambiguous characters (0, O, I, l) to reduce transcription errors

// Base58Check checksum computation
version = 0x00                              // mainnet P2PKH
payload = RIPEMD160(SHA256(public_key))     // 20-byte pubkey hash
data    = version + payload                 // 21 bytes
hash    = SHA256(SHA256(data))              // 32-byte double hash
checksum = hash[0:4]                        // first 4 bytes
address  = Base58Encode(data + checksum)    // final address

The 4-byte (32-bit) checksum means the probability of a random error going undetected is approximately 1 in 2³² (roughly 1 in 4.29 billion). However, because SHA-256 is a hash function rather than a structured algebraic code, Base58Check offers no formal guarantee about which error patterns it will catch. It treats all errors probabilistically.

Bech32 and Bech32m (SegWit and Taproot Addresses)

Modern SegWit and Taproot addresses use Bech32 (defined in BIP 173) and Bech32m (defined in BIP 350), which replace the hash-based checksum with a BCH (Bose-Chaudhuri-Hocquenghem) error-detecting code over the finite field GF(32).

The Bech32 checksum is 6 characters long (30 bits in base-32) and provides mathematically provable detection guarantees:

• Any error affecting 1 to 4 characters is guaranteed to be detected (probability of missing the error is exactly zero) for addresses up to 89 characters
• For 5 or more random substitution errors, the probability of an undetected error is less than 1 in 10⁹ (one billion)
• As the number of errors grows, the undetected error probability converges toward 1 in 2³⁰ (approximately 1 in 1.07 billion)

A valid Bech32 address satisfies the polynomial check PolyMod(codeword) = 1. Bech32m changes this constant to 0x2bc830a3, which fixes a specific vulnerability in original Bech32: whenever the last character of a Bech32 string was "p", inserting or deleting "q" characters immediately before it would not invalidate the checksum.

Version 0 witness programs (P2WPKH, P2WSH) use original Bech32, while version 1 and above (including P2TR Taproot addresses) use Bech32m.

P2P Network Message Checksums

Bitcoin's peer-to-peer protocol also uses checksums to protect network messages from corruption in transit. Every message header includes a 4-byte checksum computed as the first 4 bytes of the double SHA-256 hash of the message payload.

// Bitcoin P2P message header (24 bytes)
+----------------+------------------+
| Field          | Size             |
+----------------+------------------+
| Magic number   | 4 bytes          |
| Command name   | 12 bytes (ASCII) |
| Payload size   | 4 bytes          |
| Checksum       | 4 bytes          |
+----------------+------------------+

checksum = SHA256(SHA256(payload))[0:4]

Receiving nodes verify the checksum after downloading the full payload. If it does not match, the message is discarded and the node may request retransmission.

Seed Phrase Checksums

BIP-39 seed phrases embed a checksum directly in the mnemonic word sequence. After generating random entropy, the wallet computes SHA-256 of the entropy and uses the first few bits of the hash as a checksum. For a standard 12-word phrase (128 bits of entropy), the checksum is 4 bits; for a 24-word phrase (256 bits), it is 8 bits. The checksum bits are appended to the entropy and the combined bit string is split into 11-bit groups, each mapping to one word from the 2,048-word BIP-39 wordlist. If any word is changed, the embedded checksum will almost certainly not match, and the wallet will reject the phrase.

Error Detection vs. Error Correction

Checksums are error-detecting codes: they tell you that something went wrong but not what. An error-correcting code, by contrast, carries enough redundancy to identify and fix the corrupted bits without retransmission. Hamming codes and Reed-Solomon codes are common examples of error-correcting schemes.

Bitcoin deliberately uses detection-only checksums. The reasoning is straightforward: in a financial system, silently "correcting" an address to the wrong value would send funds to an unintended recipient with no way to recover them. It is far safer to reject the address and force the user to re-enter it.

Interestingly, the BCH code underlying Bech32 is technically capable of locating errors (BCH codes are a class of error-correcting code being used here in detection-only mode). BIP 173 notes that implementations may use this capability to highlight where a typo likely occurred, but must never auto-correct the address. Showing the user which character might be wrong helps them fix it; changing the address for them would be dangerous.

Checksum Scheme Comparison

Although Base58Check has a marginally lower raw undetected-error probability (2^-32 vs. 2^-30), Bech32's algebraic structure provides guaranteed detection of the most common real-world error patterns (1 to 4 character typos), making it the stronger scheme in practice. For a deeper comparison of address formats, see the research article on Bitcoin address types from P2PKH to Taproot.

Why It Matters

Bitcoin transactions are irreversible. If you send funds to a mistyped address that happens to be valid, there is no chargeback, no customer support, and no recovery mechanism. Checksums are the first and most important line of defense against this scenario.

Every wallet, exchange, and payment service verifies checksums before broadcasting a transaction. This single check prevents the vast majority of accidental fund loss from transcription errors: partial copies, extra whitespace, transposed characters, and dropped digits are all caught before they can cause damage. Layer 2 systems like Spark inherit these protections because they rely on the same underlying address encodings and cryptographic primitives.

Risks and Considerations

Checksums Do Not Prevent Clipboard Attacks

Clipboard hijacking malware monitors the system clipboard and replaces copied Bitcoin addresses with attacker-controlled addresses. Because the replacement address has a perfectly valid checksum, the wallet accepts it without complaint. The user believes they are sending to the intended recipient, but funds go to the attacker. Some malware families generate lookalike addresses that match the first and last several characters of the original address, making visual inspection unreliable.

Checksums protect against accidental errors, not deliberate substitution. Defending against clipboard attacks requires verifying addresses through independent channels, using hardware wallets that display the address on a separate screen, or employing tools like address poisoning detection.

No Protection Against Valid Wrong Addresses

A checksum tells you whether an address is well-formed, not whether it is the right one. If you accidentally paste a different valid address (your own old address, an address from a previous transaction, or an attacker's address from a phishing message), the checksum will pass and the transaction will proceed.

Non-Zero Probability of Undetected Errors

No checksum is perfect. There is always a small but nonzero chance that a corrupted address will still pass validation. For Base58Check, the odds are roughly 1 in 4.29 billion per error. For Bech32, any single error within the detection guarantee (up to 4 characters) is caught with certainty, but exotic multi-character corruption patterns could theoretically slip through at a rate of roughly 1 in a billion. In practice, a user is far more likely to encounter a clipboard attack than an undetected checksum collision.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.