Bitcoin address

A transaction output contains an amount and scriptPubKey bytes; it does not contain the familiar address text. A wallet decodes an address, checks its network and checksum, then constructs a standard script such as OP_DUP OP_HASH160 <20-byte hash> OP_EQUALVERIFY OP_CHECKSIG or a versioned witness program. Block explorers reverse recognizable scripts into addresses for display. Nonstandard scripts and early pay-to-pubkey outputs need not have a canonical address at all. [Bitcoin whitepaper — Transactions and Privacy] [Bitcoin Core — destination encoders and decoders]

Base58Check serializes a version byte and payload, appends the first four bytes of SHA256(SHA256(version || payload)), and Base58-encodes the result. On Bitcoin mainnet, version 0x00 denotes P2PKH and 0x05 denotes P2SH, producing the familiar leading 1 or 3; test networks use different version bytes. The alphabet omits 0, O, I and l. The checksum catches many transcription errors, but it is only 32 bits and is not a signature or recipient authentication. [Bitcoin Core — Base58Check implementation] [Bitcoin Core — destination encoders and decoders]

A native SegWit address has a human-readable part such as bc for mainnet or tb for testnet, separator 1, witness version, converted 5-bit data and a six-character polymod checksum. BIP173 assigns Bech32 only to witness version 0; BIP350 requires Bech32m for versions 1–16 after an insertion/deletion weakness was identified. Strings may be uniformly lower- or uppercase but never mixed, and the whole encoding is at most 90 characters. A valid encoding can still name the wrong network or an unsupported future witness version. [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later]

P2PKH and P2WPKH commit to a 20-byte HASH160 of a public key. P2SH commits to HASH160 of a redeemScript; P2WSH commits to SHA256 of a witnessScript. SegWit v0 therefore recognizes exactly 20-byte P2WPKH and 32-byte P2WSH programs. P2TR is different: its v1, 32-byte program is a tweaked x-only output key Q that may also commit to a Merkle root of scripts, not a hash of an ordinary receiving public key. The address alone does not reveal the complete spending policy. [BIP 141 — Segregated Witness consensus layer] [BIP 341 — Taproot validation and output keys]

Bitcoin's earliest outputs often paid directly to a public key. Pay-to-public-key-hash moved the key reveal to spending and Base58Check made human exchange safer. BIP13/BIP16 shifted complex conditions behind P2SH so the sender only committed to a script hash. BIP141 introduced versioned witness programs; BIP173 supplied Bech32 for v0. Taproot's BIP341 v1 output required Bech32m under BIP350. These are script and consensus evolutions—not cosmetic prefix changes—and manual ‘conversion’ between formats can change the spending condition or make funds unspendable. [BIP 13 — Address Format for pay-to-script-hash] [BIP 16 — Pay to Script Hash] [BIP 141 — Segregated Witness consensus layer] [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later] [BIP 341 — Taproot validation and output keys]

BIP32 wallets derive many keys from an extended root. Common receive paths separate script families: BIP44 uses purpose 44' for P2PKH, BIP84 uses 84' for native P2WPKH and BIP86 uses 86' for single-key P2TR; each then separates account, external/change branch and address index. A seed phrase by itself may not identify the script type, derivation path, accounts or multisignature policy. Output descriptors preserve keys, origins, branches and script construction more completely, so tested recovery requires more than regenerating one familiar address. [BIP 32 — Hierarchical deterministic wallets] [BIP 44 — Multi-account hierarchy] [BIP 84 — Derivation for native P2WPKH] [BIP 86 — Derivation for single-key P2TR] [Bitcoin Core — Output descriptors]

A P2PKH or P2WPKH address initially exposes a key hash; spending normally reveals the public key. P2SH and P2WSH reveal their redeemScript or witnessScript when that path is spent. A P2TR output already contains a tweaked x-only output key; a key-path spend reveals only a Schnorr signature, while a script-path spend reveals the chosen leaf, control block and Merkle path but can keep unused leaves hidden. These distinctions matter for privacy and long-term cryptographic exposure; the slogan ‘an address hides the public key’ is not universally true. [BIP 141 — Segregated Witness consensus layer] [BIP 341 — Taproot validation and output keys]

Reusing a receiving address lets observers link payments to the same locking script and often strengthens wallet-clustering heuristics. Wallets therefore derive a fresh external address and send change to an internal branch. Yet an address is not a person: several people may control one script, one person may control thousands, and custodial services pool users. An explorer's address ‘balance’ is an indexer's sum of currently unspent outputs matching a recognized script, not a consensus account field. Common-input and change heuristics are evidence with failure cases, not ownership proofs. [Bitcoin whitepaper — Transactions and Privacy] [Bitcoin Core — Output descriptors]

Software should reject a bad checksum, wrong network, mixed case and a witness-version/checksum mismatch. That does not stop clipboard malware from substituting a different, perfectly valid address, a compromised website from showing its own QR code, or a user from selecting the wrong contact. For a material payment, verify the complete address or payment request on a trusted display—ideally the hardware wallet's screen—and consider a small test transaction. Comparing only the first and last characters is vulnerable to look-alike generation; a confirmed payment to the wrong valid script has no protocol-level undo. [Bitcoin Core — Base58Check implementation] [BIP 173 — Base32 address format for native v0 witness outputs] [BIP 350 — Bech32m format for witness v1 and later]

A bare address differs from a BIP21 bitcoin: URI, which can carry an amount, label, message or other payment instruction. It also differs from a Lightning invoice, offer or Lightning Address; those identify an off-chain payment flow and may sometimes be embedded alongside an on-chain fallback. BIP322 message signing can demonstrate control of a script under a defined scheme, but does not establish legal identity, ownership of every output or authorization for a particular invoice. For complex policies and backups, use descriptors or the wallet's native export rather than treating an address as a complete wallet specification. [BIP 21 — URI scheme] [BIP 322 — Generic signed message format] [Bitcoin Core — Output descriptors]