How does the mechanism work?

On the main network, legacy public-key-hash addresses commonly begin with 1, script-hash addresses with 3, native witness addresses with bc1q, and Taproot addresses with bc1p. Witness addresses use checksum encodings defined for their witness version.

The text you copy is decoded into data used to construct an output. The eventual spend must satisfy that output’s conditions. An address is therefore a receiving instruction rather than a box containing coins.

It helps to trace receiving and spending as separate events. Receiving constructs a new output from a decoded destination. Spending later supplies evidence for that output’s rules. You may see a public key or a script for the first time at spending, although the earlier output already committed to related information. That delayed disclosure is part of the construction, not a change of ownership caused by the address text. When comparing address families, ask what is committed at creation and what must be revealed at spending. Those questions explain more than sorting destinations by how modern their prefixes look.

An address describes an output destinationLegacy and witness address families encode different destinations. The text prefix is only a clue; decoding and checksum checks are still needed.Address encodes adestinationLegacy formsWitness formsSeparate roles, shared context
Address families encode destinations; they do not certify a recipient or a service.

What would you see in an example?

Suppose a recipient gives you a bc1p destination while an older sending interface rejects it. That may be an address-format compatibility issue. It does not mean the destination belongs to another asset, and changing the prefix by hand cannot make it compatible. The encoded data and checksum must agree.

How do version and program length identify an output?

An address is a compact encoding of instructions for constructing an output. To inspect its meaning, decode the text, establish the intended network and examine the payload. Main-network prefixes are useful clues, but a clue is not a full validation. A checksum and a valid witness version must agree with the payload before an interface can build the intended destination.

Consider a version-0 witness destination with a 20-byte program. The standard pay-to-witness-public-key-hash output script contains a version opcode and a push of that program: 1 + 1 + 20 = 22 bytes. A version-0 program of 32 bytes instead describes a witness-script-hash destination. Its output script occupies 34 bytes. These are actual protocol lengths, not payment amounts.

A Taproot destination uses witness version 1 with a 32-byte program and the Bech32m checksum variant. Its output script is also 34 bytes, but equal script length does not make its spending rules identical to the version-0 script-hash case. The version is interpreted as well as the program. This is why replacing a few characters in an address cannot convert an output type.

For an invented comparison, suppose two recipients request equal payments, one to a version-0 key-hash destination and one to a Taproot destination. You can predict that the new output scripts have different lengths. You cannot yet predict the total size of either future spending transaction: the inputs, witnesses, number of outputs and chosen spending paths still matter. Address type is one part of that explanation.

Worked mechanism sequenceConsider a version-0 witness destination with a 20-byte program. The standard pay-to-witness-public-key-hash output script contains a version opcode and a push of that program: 1 + 1 + 20 = 22 bytes. A version-0 program of 32 bytes instead describes a witness-script-hash destination. Its output script occupies 34 bytes. These are actual protocol lengths, not payment amounts.Read witness versionDecode program lengthApply version-specific rules
Follow the example in the text. Monetary amounts and fee rates are invented, not live observations.

Common misunderstandings

A longer address does not mean a larger payment or stronger ownership evidence. Address text has encoding overhead, while fees are based on transaction weight. Counting displayed characters is not a transaction-size calculator.

A checksum tests the integrity of an encoding, not the recipient’s identity. A substituted address can have a perfectly valid checksum. Likewise, a recognised prefix does not mean an older sending system supports every spend construction behind it. Decode and validate the whole destination.

Check yourself

Are all 32-byte witness programs interpreted in the same way?

Reveal the answer

No. The witness version and the program length work together. Version 0 script-hash and version 1 Taproot outputs have different spending rules.

What does this diagram leave out?

A checksum can catch many transcription mistakes, but it cannot tell whether an address belongs to the person you intended. This lesson shows prefixes only; it provides no destination to send funds to. Verify the destination through your established receiving process.