Script types and address formats

An address is a human-friendly encoding of a locking script. Its format tells an analyst which script type is in use, which narrows down the wallet software and the era it came from, and it determines what information will become public when the coins are spent. Reading formats fluently, and knowing what multisig and Taproot hide or reveal, is basic tradecraft for anyone working with UTXO data.

From script to address

Addresses do not appear on chain. What the chain stores is the scriptPubKey; explorers and decoders convert it into an address for display. Each standard script type maps to one encoding and one recognizable prefix (the scripts themselves are dissected in the lesson Raw Bitcoin transactions):

Testnets use different prefixes (m or n for P2PKH, 2 for P2SH, tb1 for SegWit), so a stray testnet address in a dataset is easy to spot. Some older scripts, such as pay-to-public-key outputs from the early mining era and bare multisig, have no standard address at all; explorers show the public key or a synthetic label, and data warehouses may leave the address column empty. A query that filters on address IS NOT NULL silently drops them.

Base58Check

Legacy addresses use Base58Check. The encoder takes a version byte, appends the 20-byte payload (a HASH160 of a public key or of a script), computes a checksum, and writes the result in a 58-character alphabet that leaves out the easily confused characters 0, O, I and l.

version byte   00                -> mainnet P2PKH, so the string starts with "1"
payload        20-byte HASH160 of a public key
checksum       first 4 bytes of SHA-256(SHA-256(version || payload))
encoded        Base58 of the 25 bytes -> 1Fx3…9qLm

Each leading zero byte becomes a leading 1, which is why every P2PKH address starts with that character. Base58Check is case-sensitive, and the 4-byte checksum means a mistyped address is almost always rejected. For analysts, the version byte is the classification key: 0x00 means P2PKH, 0x05 means P2SH, and anything else is another network or another coin.

Bech32 and bech32m

Native SegWit addresses use bech32, defined in BIP-173. A bech32 string has three parts: a human-readable part (bc for mainnet, tb for testnet), the separator 1, and a data part written in a 32-character alphabet that excludes 1, b, i and o. The first data character is the witness version (q is version 0, p is version 1), followed by the witness program and a 6-character checksum.

bc1q…7k3f            42 characters
hrp        bc        -> Bitcoin mainnet
separator  1
version    q = 0     -> SegWit v0, so the checksum must be bech32
program    20 bytes  -> P2WPKH (a 32-byte program would be P2WSH)
checksum   last 6 characters

Bech32 is all lowercase (uppercase is allowed for QR codes, but decoders must reject mixed case), at most 90 characters long, and its checksum is guaranteed to detect any error affecting up to four characters. It has one flaw: when a string ends in p, inserting or deleting q characters just before that p can leave the checksum valid. For version 0, the strict program lengths (20 or 32 bytes) make this mostly harmless. Later versions allow other lengths, so BIP-350 introduced bech32m, identical except for the constant used in the checksum (0x2bc830a3 instead of 1). Version 0 addresses keep bech32; versions 1 to 16, including Taproot, use bech32m. A decoder must reject a version 1 address with a bech32 checksum and a version 0 address with a bech32m checksum.

Practical points for pipelines: do not classify on "starts with bc1" alone; read the fourth character (q or p) and the length. Parsers written before 2021 may reject valid bc1p addresses or treat them as errors, and a pipeline that drops unparseable rows will under-count Taproot activity without any warning.

What the format reveals about wallets

Address formats track wallet history, so they carry information about the software behind them:

• 1… (P2PKH): old wallets, legacy-only services, and some long-standing exchange wallets. Fresh P2PKH activity today often points to older or custom software.
• 3… (P2SH): ambiguous until spent. It may be a multisig wallet, or a single-key wallet using nested SegWit (P2SH-wrapped P2WPKH), which was a common default around 2017–2019.
• bc1q… (v0 SegWit): the default receive type of most mainstream wallets in recent years. P2WSH (62 characters) usually means a multisig or other custom script.
• bc1p… (Taproot): wallets that adopted Taproot after its activation at block 709,632 in November 2021, plus inscription and token tooling that relies on it.

When a 3… output is spent, the redeem script appears in the input and resolves the ambiguity: a redeem script of 0014 plus 20 bytes is nested P2WPKH, 0020 plus 32 bytes is nested P2WSH, and one ending in ae (OP_CHECKMULTISIG) is a classic multisig.

Script types also mix within transactions. If all inputs are P2WPKH and the two outputs are one P2WPKH and one P2SH, the output matching the input type is more likely to be change. The address type is one of several wallet fingerprints, alongside transaction version, lock time and sequence values, and signature encoding; the lesson Change detection heuristics explains how to combine them and how much confidence they deserve.

Multisig and its footprint

Classic multisig uses OP_CHECKMULTISIG inside a P2SH redeem script or a P2WSH witness script. The policy stays hidden while funds sit unspent (only a hash is on chain) but becomes fully public at the first spend. A decoded 2-of-3 P2WSH input looks like this:

witness[0]  (empty)            -- dummy element required by OP_CHECKMULTISIG
witness[1]  3044…01            -- first signature (DER, sighash byte 01)
witness[2]  3045…01            -- second signature
witness[3]  5221…21…21…53ae    -- OP_2 <key1> <key2> <key3> OP_3 OP_CHECKMULTISIG

In the witness script, 52 is OP_2 (two signatures required), each 21 pushes a 33-byte compressed public key, 53 is OP_3 (three keys) and ae is OP_CHECKMULTISIG. One spend reveals the threshold, all three public keys, and which two keys signed.

This footprint is rich evidence. Custodians often run distinctive policies (2-of-3, 3-of-5) for cold storage, and the same public key appearing in many multisig scripts links those addresses to one key holder far more reliably than behavioral heuristics. Many wallets sort keys in lexicographic order (BIP-67), which is itself a small fingerprint.

Taproot and privacy

Taproot combines three pieces. BIP-340 defines Schnorr signatures on the same secp256k1 curve: fixed 64-byte signatures and 32-byte "x-only" public keys. BIP-341 defines the output: OP_1 followed by a 32-byte key Q, where Q = P + t·G, P is an internal key, and the tweak t commits to P and to the Merkle root of an optional tree of alternative scripts. BIP-342 defines the script rules inside that tree, replacing OP_CHECKMULTISIG with OP_CHECKSIGADD.

A Taproot output can be spent two ways, and they reveal very different amounts:

On the key path, a single-key wallet, an n-of-n group using key aggregation (MuSig2) and a threshold signing scheme all produce the same thing: one signature for one key. The script path reveals only the leaf actually used; unused branches stay hidden, although the Merkle path length leaks something about the tree's size, which BIP-341 itself notes can help clustering.

For analysts, Taproot removes the multisig footprint described above whenever the key path is used, so custody policies become invisible. It does not hide amounts, the transaction graph or timing, and while adoption is modest, the bc1p format itself is a distinguishing feature. Script-path spends also carry inscriptions: since 2023, large witnesses with an OP_FALSE OP_IF … OP_ENDIF "envelope" have been used to embed images and token data, a pattern worth filtering out of payment analysis.

Exam focus: mapping prefixes and lengths to script types (1, 3, bc1q at 42 and 62 characters, bc1p at 62); Base58Check structure (version byte, 4-byte double SHA-256 checksum, version 0x00 vs 0x05); bech32 structure (hrp, separator 1, witness version character, 6-character checksum) and the BIP-350 change to bech32m for witness version 1 and above; why "starts with bc1" is not a classification; how a spent P2SH output resolves into nested SegWit or multisig; what a classic multisig spend reveals; Taproot key-path vs script-path spends, Q = P + t·G, and the 33 + 32m control block; what Taproot hides and what it does not.