BA-04 · LESSON 02

Base58, Bech32, and Bech32m

KEY DEFINITIONS

Terms used in this lesson

Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
Taproot: A Bitcoin output and spending design that can combine a public-key path with privately committed alternative scripts.
Signet: A Bitcoin test network whose blocks require authorization by a configured signing challenge.
Regtest: A private Bitcoin test network where the operator can create blocks instantly for repeatable experiments.
SHA-256: A cryptographic hash function used throughout Bitcoin to produce fixed-size 256-bit digests.

Bitcoin addresses are human-readable encodings with a network marker and error-detecting checksum. Three formats exist because Bitcoin added new spending types over time.

45 min Difficulty 1/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 · address encodingAn address encodes a network and witness programSelect any state to inspect its exact role.

RELATIONSHIP MAPCommitment and derivation tree

01
PUBLIC KEY33-byte compressed point
A P2WPKH wallet hashes a valid serialized secp256k1 point.
02
HASH16020-byte program A
SHA-256 followed by RIPEMD-160 creates the witness program.
03
NETWORKMainnet hrp bc
The human-readable prefix prevents accidental cross-network use.
04
BECH32bc1q... checksum
Witness version 0 uses Bech32 and converts the program to 5-bit groups.
05
SCRIPTOP_0 PUSH20 <program>
The transaction stores this scriptPubKey, not the address string.

Rule shown: Wallets decode and validate address text before constructing the output script; the address itself is not stored on chain.

STAGE 1 OF 5PUBLIC KEY: 33-byte compressed point

A P2WPKH wallet hashes a valid serialized secp256k1 point.

Governing relationship: Wallets decode and validate address text before constructing the output script; the address itself is not stored on chain. Complete path: 1. PUBLIC KEY, 33-byte compressed point. A P2WPKH wallet hashes a valid serialized secp256k1 point. 2. HASH160, 20-byte program A. SHA-256 followed by RIPEMD-160 creates the witness program. 3. NETWORK, Mainnet hrp bc. The human-readable prefix prevents accidental cross-network use. 4. BECH32, bc1q... checksum. Witness version 0 uses Bech32 and converts the program to 5-bit groups. 5. SCRIPT, OP_0 PUSH20 <program>. The transaction stores this scriptPubKey, not the address string.

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

BEFORE

A mainnet wallet is given an address beginning tb1p.

MECHANISM

A wallet first has a script-related payload, such as a 20-byte key hash or a witness version plus witness program. The text does not create the condition.

AFTER

A checksum checks encoding integrity, not whether the recipient or network is intended.

Text equivalent: Starting from A mainnet wallet is given an address beginning tb1p. The mechanism begins when A wallet first has a script-related payload, such as a 20-byte key hash or a witness version plus witness program. The text does not create the condition. The resulting lesson is A checksum checks encoding integrity, not whether the recipient or network is intended.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Start from a payload

A wallet first has a script-related payload, such as a 20-byte key hash or a witness version plus witness program. The text does not create the condition.

Complete path: 1. Start from a payload: A wallet first has a script-related payload, such as a 20-byte key hash or a witness version plus witness program. The text does not create the condition. 2. Add network information: Base58Check uses version bytes. Bech32-family addresses use a human-readable prefix such as bc for mainnet, tb for testnet and signet, or bcrt for regtest. 3. Convert the data alphabet: Base58 avoids visually ambiguous characters. Bech32-family encodings convert data to five-bit symbols using a 32-character alphabet. 4. Compute the correct checksum: Base58Check uses four bytes from a double-SHA-256 checksum. Bech32 and Bech32m use different checksum constants, selected by witness version. 5. Decode before paying: Wallets verify the checksum, network, witness version, and program length, then construct the corresponding output script.

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

ACCEPTED PATH

The decoder checks the complete checksum, network prefix or version byte, witness version, and program length before constructing a script.

CHANGED CONDITION

A valid tb1p checksum still fails a mainnet intent check, while one corrupted checksum character must be rejected before payment construction.

Important distinction: A valid address checksum proves the payment is going to the intended person. It detects many encoding errors. It does not authenticate the recipient, protect against clipboard replacement with another valid address, or fix a network mismatch.

Text equivalent: The accepted path is enforced by The decoder checks the complete checksum, network prefix or version byte, witness version, and program length before constructing a script. If the required condition changes, A valid tb1p checksum still fails a mainnet intent check, while one corrupted checksum character must be rejected before payment construction.

Loading lesson visuals...

Learn the idea

Base58Check, Bech32, and Bech32m are text encodings used for Bitcoin destinations. Each carries network or version information and a checksum that detects many typing errors. Base58Check is used for legacy address families. Bech32 encodes witness version 0, while Bech32m is required for witness versions 1 through 16, including Taproot version 1.

GUIDED EXPLANATION1/5 ideas inspected

Start from a payload

A wallet first has a script-related payload, such as a 20-byte key hash or a witness version plus witness program. The text does not create the condition.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A valid address checksum proves the payment is going to the intended person.”

It detects many encoding errors. It does not authenticate the recipient, protect against clipboard replacement with another valid address, or fix a network mismatch.

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.