BA-04 · LESSON 11

WIF, Base58Check, Bech32, Bech32m, and checksums

KEY DEFINITIONS

Terms used in this lesson

WIF: Wallet Import Format, a Base58Check text encoding for a Bitcoin private scalar plus network and public-key compression metadata.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
P2PKH: Pay to Public Key Hash, a legacy Bitcoin output template that commits to the hash of a public key.
P2WPKH: Pay to Witness Public Key Hash: a native SegWit output for one public-key hash.
P2TR: Pay to Taproot, the Bitcoin output type introduced with Taproot.
SegWit: Segregated Witness: a Bitcoin upgrade that separates authorization data from the transaction identifier and introduces versioned witness programs.
HASH256: Bitcoin's name for applying SHA-256 twice to the same byte sequence.

Encode and decode private-key and destination text formats byte by byte, including network markers, witness versions, conversion alphabets, and checksum limits.

55 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · bitcoin encodingsNetwork bytes and checksums make Bitcoin text decodableSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
PAYLOADKey or witness program
Start from exact version, network, key, hash, or witness bytes.
02
ALPHABETBase58 or 5-bit Bech32
Conversion preserves bytes while avoiding ambiguous characters or fitting the checksum code.
03
CHECKSUMHASH256 or polymod
The checksum family is selected by encoding and witness version.
04
NETWORKMainnet bc or version
Network markers prevent accidental cross-network acceptance when wallets check them.
05
DECODEValid WIF or ScriptPubKey
A checksum detects errors but does not authenticate the intended recipient.

Rule shown: Base58Check, WIF, Bech32, and Bech32m carry different payloads and must be decoded before keys or scripts are constructed.

STAGE 1 OF 5PAYLOAD: Key or witness program

Start from exact version, network, key, hash, or witness bytes.

Governing relationship: Base58Check, WIF, Bech32, and Bech32m carry different payloads and must be decoded before keys or scripts are constructed. Complete path: 1. PAYLOAD, Key or witness program. Start from exact version, network, key, hash, or witness bytes. 2. ALPHABET, Base58 or 5-bit Bech32. Conversion preserves bytes while avoiding ambiguous characters or fitting the checksum code. 3. CHECKSUM, HASH256 or polymod. The checksum family is selected by encoding and witness version. 4. NETWORK, Mainnet bc or version. Network markers prevent accidental cross-network acceptance when wallets check them. 5. DECODE, Valid WIF or ScriptPubKey. A checksum detects errors but does not authenticate the intended recipient.

1. State transitionWhat exists, what changes, and what results

BEFORE

Encode one disposable mainnet scalar and two destination programs.

MECHANISM

Concatenate the version byte and payload, append the first four bytes of HASH256, convert the whole big-endian integer to the Base58 alphabet, and preserve each leading zero…

AFTER

Encoding protects byte transport; trusted-display comparison protects intent.

Text equivalent: Starting from Encode one disposable mainnet scalar and two destination programs. The mechanism begins when Concatenate the version byte and payload, append the first four bytes of HASH256, convert the whole big-endian integer to the Base58 alphabet, and preserve each leading zero byte as a leading 1 character. The resulting lesson is Encoding protects byte transport; trusted-display comparison protects intent.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Build Base58Check bytes

Concatenate the version byte and payload, append the first four bytes of HASH256, convert the whole big-endian integer to the Base58 alphabet, and preserve each leading zero byte as a leading 1 character.

Complete path: 1. Build Base58Check bytes: Concatenate the version byte and payload, append the first four bytes of HASH256, convert the whole big-endian integer to the Base58 alphabet, and preserve each leading zero byte as a leading 1 character. 2. Encode WIF metadata: Mainnet WIF starts from version 80 followed by the 32-byte private scalar. A trailing 01 means wallets should derive compressed public keys. Test networks use version ef. 3. Build a Bech32 data part: Use a human-readable prefix such as bc, tb, or bcrt, append the witness version, and convert the witness program from eight-bit bytes to five-bit symbols without changing the underlying program. 4. Choose the checksum constant: Witness version 0 uses Bech32. Witness versions 1 through 16 use Bech32m. The polymod calculation covers the expanded prefix, data symbols, and six checksum symbols. 5. Decode before constructing Script: A wallet rejects mixed case, invalid alphabet, checksum failure, wrong network, invalid witness version or program length, and invalid private scalar before producing a key or output script.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The decoder validates alphabet, case, version, payload length, network, checksum family, scalar or point boundaries, and exact conversion before returning structured bytes.

CHANGED CONDITION

A valid checksum cannot detect a deliberately substituted valid address, and WIF text must never be pasted into a public website or shared as a payment instruction.

Important distinction: Bech32 and Base58 are cryptographic protections that make the encoded key or address secret. They are public text encodings with checksums. WIF contains a private key and must remain secret despite its checksum.

Text equivalent: The accepted path is enforced by The decoder validates alphabet, case, version, payload length, network, checksum family, scalar or point boundaries, and exact conversion before returning structured bytes. If the required condition changes, A valid checksum cannot detect a deliberately substituted valid address, and WIF text must never be pasted into a public website or shared as a payment instruction.

Loading lesson visuals...

Learn the idea

Bitcoin text encodings carry exact bytes plus error-detecting checksums. Wallet Import Format, called WIF, encodes a private scalar with network and compression metadata using Base58Check. Legacy addresses also use Base58Check. SegWit addresses use Bech32 for witness version 0 and Bech32m for versions 1 through 16. A checksum detects many mistakes but does not authenticate the intended recipient.

GUIDED EXPLANATION1/5 ideas inspected

Build Base58Check bytes

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Bech32 and Base58 are cryptographic protections that make the encoded key or address secret.”

They are public text encodings with checksums. WIF contains a private key and must remain secret despite its checksum.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.