Skip to content

Instantly share code, notes, and snippets.

@kenorb

kenorb/bitcoin-address-types.md

Last active June 22, 2025 18:22
Show Gist options
  • Save kenorb/2b9a4e9c6ff74a11b0bb21afe1a81348 to your computer and use it in GitHub Desktop.
Save kenorb/2b9a4e9c6ff74a11b0bb21afe1a81348 to your computer and use it in GitHub Desktop.
Download ZIP
Summary of Bitcoin Mainnet Addresses and Non-Standard Outputs (Grok AI)
Raw
bitcoin-address-types.md

Comprehensive Overview of Bitcoin Mainnet Addresses

This document provides a detailed summary of all Bitcoin mainnet address types, including standard formats (Legacy, SegWit, Taproot), non-standard Bech32 variants (e.g., bc10, bc1s), and Blockchair-specific non-standard outputs (s-, d-, m-). It reflects the Bitcoin protocol as of June 22, 2025, incorporating insights from the Bitcoin Wiki: Script and recent analyses of non-standard address formats.

Standard Bitcoin Mainnet Addresses

Standard addresses are encoded identifiers for spendable transaction outputs, using Base58Check or Bech32/Bech32m formats. They are derived from public keys or scripts and are fully supported by wallets and blockchain explorers.

Legacy Addresses

1. Pay-to-Public-Key-Hash (P2PKH)

  • Starting Character: 1
  • Format: Base58Check encoding
  • Length: 26–35 characters
  • ScriptPubKey: OP_DUP OP_HASH160 <20-byte-pubkey-hash> OP_EQUALVERIFY OP_CHECKSIG
  • Example: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
  • Functionality:
    • Locks funds to a 20-byte hash of a public key (RIPEMD160(SHA256(pubkey))).
    • Spending requires a signature and the public key matching the hash.
  • Spendability: Yes, with a valid signature and public key.
  • Conversion: Derived from a public key via hashing and Base58Check encoding with version byte 0x00.
  • Use Case: Single-signature transactions, common in early Bitcoin and still widely used.

2. Pay-to-Script-Hash (P2SH)

  • Starting Character: 3
  • Format: Base58Check encoding
  • Length: 26–35 characters
  • ScriptPubKey: OP_HASH160 <20-byte-script-hash> OP_EQUAL
  • Example: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
  • Functionality:
    • Locks funds to a 20-byte hash of a redeem script (e.g., multisig or complex script).
    • Spending requires the redeem script and inputs satisfying its conditions (e.g., multiple signatures for multisig).
  • Spendability: Yes, if the redeem script’s conditions are met.
  • Conversion: Hash the redeem script (RIPEMD160(SHA256(script))) and encode with version byte 0x05.
  • Use Case: Multisig wallets, complex scripts, backward-compatible with older nodes.

SegWit and Taproot Addresses

1. Pay-to-Witness-Public-Key-Hash (P2WPKH)

  • Starting Characters: bc1q
  • Format: Bech32 encoding
  • Length: 42 characters
  • ScriptPubKey: 0 <20-byte-pubkey-hash>
  • Example: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
  • Functionality:
    • SegWit version of P2PKH, locking funds to a 20-byte public key hash with witness version 0.
    • Witness data (signature, public key) is stored separately, reducing transaction size and fees.
    • Spending requires a signature and public key in the witness field.
  • Spendability: Yes, with a valid signature and public key.
  • Conversion: Hash the public key (RIPEMD160(SHA256(pubkey))) and encode with Bech32 (version 0, mainnet prefix bc).
  • Use Case: Single-signature transactions with lower fees and improved scalability.

2. Pay-to-Witness-Script-Hash (P2WSH)

  • Starting Characters: bc1q
  • Format: Bech32 encoding
  • Length: 62 characters
  • ScriptPubKey: 0 <32-byte-script-hash>
  • Example: bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7
  • Functionality:
    • Locks funds to a 32-byte hash of a witness script with witness version 0.
    • Spending requires the witness script and inputs satisfying its conditions (e.g., multisig).
  • Spendability: Yes, if the witness script’s conditions are met.
  • Conversion: Hash the witness script (SHA256(script)) and encode with Bech32 (version 0, mainnet prefix bc).
  • Use Case: Multisig or complex scripts with SegWit benefits.

3. Pay-to-Taproot (P2TR)

  • Starting Characters: bc1p
  • Format: Bech32m encoding
  • Length: 62 characters
  • ScriptPubKey: 1 <32-byte-output-key>
  • Example: bc1pmfr3p9j00pfxjh0z0r2r9x7p4fs5u3e692v8yf
  • Functionality:
    • Locks funds to a 32-byte output key (Schnorr public key or script commitment) with witness version 1.
    • Supports key-path spending (single signature) or script-path spending (complex scripts via Merkle tree).
    • Spending requires a Schnorr signature or script inputs satisfying the commitment.
  • Spendability: Yes, via key-path or script-path conditions.
  • Conversion: Encode the 32-byte output key with Bech32m (version 1, mainnet prefix bc).
  • Use Case: Advanced scripts, Schnorr signatures, improved privacy, and efficiency.

Non-Standard Bitcoin Addresses

Non-Standard Bech32 Addresses

  • Starting Characters: bc10, bc1s, bc1w, bc1v, bc1z
  • Format: Bech32 encoding
  • Length: Varies (e.g., 14, 42, or 62 characters)
  • Examples:
    • bc1zqyqsywvzqe (14 characters, too short for standard)
    • bc1sw50qgdz25j (14 characters, too short for standard)
    • bc1wxsunwefhvscngwpsxzpqhwyqq9ejka3h3xe4mx3zmwd3efq79kwvzepgxcphxt56tpa5ct (62 characters, P2TR-like)
    • bc1vq2q6p8qpnjnvsqgevsqqpvkuxhtsuf57xdh (42 characters, P2WPKH-like)
    • bc10qyqnzdqxc87n9xz3nkfmwzk5j5th2pzuchpqrmas3l (42 characters, P2WPKH-like)
  • Likely Witness Versions:
    • bc10: Witness version 15 (Bech32 character 0)
    • bc1s: Witness version 16 (Bech32 character s)
    • bc1w: Witness version 14 (Bech32 character w)
    • bc1v: Witness version 12 (Bech32 character v)
    • bc1z: Witness version 2 (Bech32 character z)
  • Functionality:
    • These addresses use Bech32 encoding but correspond to witness versions not defined in the current Bitcoin protocol (only versions 0 and 1 are active).
    • They may represent experimental formats, testnet addresses, or placeholders for future protocol upgrades.
  • Spendability: No, as these witness versions are not supported on mainnet. Transactions using these addresses are likely rejected by nodes.
  • Conversion: Cannot be translated to standard formats for spending, as their witness versions are undefined.
  • Use Case: Experimental or testnet contexts; not practical for mainnet transactions.
  • Explorer Support: May appear on explorers like Tokenview.io, but their validity for spending is questionable.

Other Non-Standard Outputs (Blockchair-Specific)

Blockchair categorizes non-standard transaction outputs with prefixes s-, d-, and m-, which are not part of the Bitcoin protocol but are used in Blockchair’s database to represent scripts that don’t fit standard address formats. These outputs use a 16-byte (32-character hexadecimal) identifier, likely a custom hash (e.g., MD5) of the script or data.

1. Non-Standard Script Outputs (s-)

  • Starting Characters: s-
  • Format: s- followed by 32 hex characters
  • Length: 34 characters (including s-)
  • Example: s-f3aa977840863c94a2dacf802e7f7d85
  • ScriptPubKey: Varies (e.g., Pay-to-PubKey: <pubkey> OP_CHECKSIG)
  • Functionality:
    • Represents scripts not convertible to standard addresses, such as Pay-to-PubKey (P2PK) used in early Bitcoin or complex scripts with unusual opcodes.
    • Example: Transaction a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b outputs to a P2PK script (4104...ac).
    • Spending requires satisfying the script’s conditions (e.g., a signature for P2PK).
  • Spendability: Yes, if the script’s conditions are met.
  • Conversion:
    • Possible if the script matches a standard format (e.g., P2PKH-like), by extracting the hash and encoding as a P2PKH (1) or P2SH (3) address.
    • Not possible for scripts like P2PK or custom scripts (e.g., s-f3aa977840863c94a2dacf802e7f7d85 is P2PK).
  • Use Case: Historical analysis, early Bitcoin transactions, or rare custom scripts.
  • Explorer Support: Visible on Blockchair via transaction IDs; other explorers (e.g., Blockstream.info) show raw scripts without s- prefix.

2. Nulldata Outputs (OP_RETURN, d-)

  • Starting Characters: d-
  • Format: d- followed by 32 hex characters
  • Length: 34 characters (including d-)
  • Example: d-06f467f5063f68e1360fcd531fe1b2a2
  • ScriptPubKey: OP_RETURN <data> (up to 80 bytes)
  • Functionality:
    • Embeds arbitrary data (e.g., metadata, messages) on the blockchain using OP_RETURN.
    • Not an address; funds sent to OP_RETURN are unspendable.
    • Blockchair uses d- to categorize these outputs, with the hex string as a custom identifier.
  • Spendability: No, OP_RETURN outputs are explicitly unspendable.
  • Conversion: Not possible, as they are data outputs, not addresses.
  • Decoding: Retrieve the transaction, extract the OP_RETURN data (e.g., 6a0d48656c6c6f20576f726c64 → “Hello World”).
  • Use Case: Token issuance, decentralized app data, blockchain timestamps.
  • Explorer Support: Visible on Blockchair; other explorers may show OP_RETURN data but not as d- addresses.

3. Bare Multisig Script Outputs (m-)

  • Starting Characters: m-
  • Format: m- followed by 32 hex characters
  • Length: 34 characters (including m-)
  • Example: m-942943e227462513f33c4f32ec6f1e56
  • ScriptPubKey: <m> <pubkey1> <pubkey2> ... <n> OP_CHECKMULTISIG
  • Functionality:
    • Represents multisig scripts without a P2SH wrapper, specifying m-of-n signatures.
    • Spending requires m signatures matching the public keys.
    • Blockchair uses m- to distinguish from P2SH multisig (starting with 3).
  • Spendability: Yes, with the required number of signatures.
  • Conversion: Possible to a P2SH address by hashing the multisig script (RIPEMD160(SHA256(script))) and encoding with version byte 0x05.
  • Use Case: Legacy multisig transactions, rare in modern Bitcoin due to P2SH preference.
  • Explorer Support: Visible on Blockchair; other explorers show raw multisig scripts without m- prefix.

Technical Overview

Bitcoin transactions lock funds to scripts (scriptPubKey) that define spending conditions, as detailed in the Bitcoin Wiki: Script. Addresses are compact representations of these scripts:

  • Standard Addresses: Encode common scripts (P2PKH, P2SH, P2WPKH, P2WSH, P2TR) for user convenience.
  • Non-Standard Bech32 Addresses: Encode scripts with undefined witness versions, making them non-functional on mainnet.
  • Blockchair Outputs: Represent raw scripts or data outputs, categorized for analysis purposes.

Decoding and Analysis

  • Standard Addresses:
    • Decode using Base58Check (P2PKH, P2SH) or Bech32/Bech32m (P2WPKH, P2WSH, P2TR) libraries (e.g., python-bitcoinlib, bitcoinjs-lib).
    • Example: P2PKH address 1A1z... → extract 20-byte hash, verify checksum.
  • Non-Standard Bech32 Addresses:
    • Decode using Bech32 libraries to extract witness version and program, but spending is not possible due to undefined versions.
    • Example: bc1zqyqsywvzqe decodes to witness version 2, invalid for mainnet.
  • Blockchair Outputs:
    • Retrieve transaction via Blockchair, extract scriptPubKey, and parse using tools like bitcoin-cli (decoderawtransaction) or python-bitcoinlib.
    • Example for s-f3aa977840863c94a2dacf802e7f7d85 (P2PK): 
      from bitcoinrpc.authproxy import AuthServiceProxy
rpc = AuthServiceProxy("http://user:pass@localhost:8332")
tx = rpc.getrawtransaction("a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b", True)
print(tx["vout"][0]["scriptPubKey"]["hex"])  # Outputs P2PK script

Spendability and Conversion Summary

Type Starting Characters Spendable? Convertible to Address? Conversion Method
P2PKH 1 Yes N/A (already an address) N/A
P2SH 3 Yes N/A (already an address) N/A
P2WPKH bc1q Yes N/A (already an address) N/A
P2WSH bc1q Yes N/A (already an address) N/A
P2TR bc1p Yes N/A (already an address) N/A
Non-Standard Bech32 bc10, bc1s, bc1w, bc1v, bc1z No No N/A; undefined witness versions
s- s- Yes, if conditions met Sometimes (e.g., P2PKH-like) Parse scriptPubKey, encode if standard
d- d- No No N/A; decode OP_RETURN data
m- m- Yes, with signatures Yes (to P2SH) Hash multisig script, encode as P2SH

Practical Notes

  • Historical Context: Non-standard outputs (s-, m-) were common in early Bitcoin (2009–2012) due to P2PK and bare multisig usage. Modern Bitcoin favors standard addresses for compatibility.
  • Non-Standard Bech32: These addresses may appear in explorers like Tokenview.io but are not practical for mainnet use. They may be relevant for future protocol upgrades or testnets.
  • Blockchair’s Role: The s-, d-, m- prefixes are Blockchair-specific, not part of Bitcoin’s protocol. The 16-byte hex identifier is a custom hash, requiring transaction data for analysis.
  • Verification: Use multiple explorers (Blockstream.info, Blockchain.com) or Bitcoin nodes to verify scripts and addresses, as explorers like Tokenview.io may display non-standard formats inconsistently.

Key Citations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment