A cryptographic hash function takes an input of arbitrary practical length and produces a fixed-size output called a hash or digest. The same input produces the same output. A small input change should unpredictably alter the digest.
Bitcoin relies on hash functions throughout transaction identification, block construction, proof of work, scripts, witness programs, Taproot, and address encodings. The word “hash” is therefore too broad by itself. Accurate explanations name the function, the serialization, the number of applications, the output length, and the purpose.
This guide was researched on July 25, 2026 against the deployed Bitcoin BIPs and Bitcoin Core 31.1 at tag v31.1, commit 9be056a8a72b624dae9623b2f7bded92c2a21c91. Cryptographic confidence is not an absolute guarantee and should be revisited if standards, attacks, implementations, or consensus proposals change.
Core security properties
Several properties are commonly discussed separately.
Preimage resistance means that, given a target digest, finding any input that hashes to it should require infeasible work.
Second-preimage resistance means that, given one particular input, finding a different input with the same digest should require infeasible work.
Collision resistance means that finding any two different inputs with the same digest should require infeasible work.
These are related but not identical goals. An attack that finds arbitrary collisions does not automatically provide a preimage for a chosen target. A protocol may depend more heavily on one property than another.
Hash outputs are not guaranteed unique. A function with a finite output space and effectively unlimited possible inputs must have collisions. Security language is probabilistic and computational: collisions should be infeasible to find within the relevant threat model, not impossible by mathematics.
Fixed-size output and the birthday bound
SHA-256 produces 256 bits, or 32 bytes. An idealized 256-bit hash has approximately 2^256 possible outputs. Finding a preimage for a chosen output is expected to require work on the order of 2^256, while finding any collision can exploit the birthday effect and is expected around 2^128 trials.
The birthday bound does not mean that ordinary users face a one-in-2^128 chance each time they hash data. It describes the scale at which a deliberate search for any pairwise collision becomes plausible in an idealized model. Real risk analysis also depends on the exact construction, attacker control, target selection, and consequences of a collision.
For 160-bit HASH160 outputs, the corresponding generic collision scale is approximately 2^80, while generic preimage work is approximately 2^160. These figures are security-model approximations, not promises about implementations or future cryptanalysis.
SHA-256
SHA-256 is a member of the SHA-2 family standardized by NIST. It processes data in blocks and returns a 32-byte digest.
Bitcoin Core 31.1 has a dedicated SHA-256 implementation and uses SHA-256 both directly and inside larger constructions. Examples include:
- the first stage of double SHA-256;
- the first stage of HASH160;
- P2WSH witness-script commitments;
- BIP 340, BIP 341, and BIP 342 tagged hashes;
- Taproot signature-message component hashes;
- the witness commitment after a second SHA-256 stage;
- proof-of-work block-header hashing as part of double SHA-256.
“Bitcoin uses SHA-256” is true but incomplete. The surrounding serialization and construction determine what the digest means.
Double SHA-256
Double SHA-256 means:
SHA256(SHA256(data))
Bitcoin Core’s CHash256, Hash, and HashWriter::GetHash() implement this 256-bit construction.
Bitcoin uses double SHA-256 for several historically important objects, including:
- transaction identifiers from the non-witness transaction serialization;
- witness transaction identifiers when witness data is present;
- block-header identifiers and proof-of-work hashes;
- parent nodes in the block transaction Merkle tree;
- the SegWit witness commitment;
- Base58Check’s checksum source before truncation;
- legacy, BIP 143, and some other signature-message digests.
Using SHA-256 twice should not be summarized as “twice as secure.” It does not double the output length or turn 256-bit collision resistance into 512-bit collision resistance. In some constructions it avoids Merkle–Damgård length-extension behavior on the inner digest, but each protocol must be analyzed in context.
BIP 341 intentionally uses single-SHA-256 component hashes and a tagged final hash for Taproot signature messages. Its rationale notes that length extension is not a concern for this public, length-committed message construction. This demonstrates why counting hash invocations is not a reliable security ranking.
HASH160
Bitcoin’s HASH160 construction is:
RIPEMD160(SHA256(data))
The result is 20 bytes. Bitcoin Core implements this as CHash160.
HASH160 appears in several legacy and SegWit version 0 constructions:
- pay-to-public-key-hash scripts commit to the HASH160 of a public key;
- pay-to-script-hash scripts commit to the HASH160 of a redeem script;
- P2WPKH witness programs commit to the HASH160 of a compressed public key.
RIPEMD-160 is therefore not used alone in these constructions. It compresses a SHA-256 digest to 160 bits.
A 20-byte key hash is not a public key. Spending a P2PKH or P2WPKH output reveals a public key whose HASH160 must match the commitment, then verifies a signature under that public key. The hash commitment and the signature check perform different jobs.
P2WSH does not use HASH160. It commits directly to SHA256(witnessScript), producing a 32-byte witness program. Treating P2SH and P2WSH as the same “script hash” hides an important output-length and construction difference.
Tagged hashes
A BIP 340-style tagged hash is:
SHA256(SHA256(tag) || SHA256(tag) || message)
The repeated tag hash fills one SHA-256 block and creates a context-specific initial state. Bitcoin Core’s TaggedHash helper and preinitialized Taproot hashers implement this pattern.
BIP 340 uses distinct tags for auxiliary data, nonce derivation, and the signature challenge. BIP 341 and BIP 342 use tags including TapTweak, TapLeaf, TapBranch, and TapSighash.
Tagged hashing provides domain separation. A digest intended as a TapLeaf commitment should not be casually interchangeable with a signature challenge or nonce input. Domain separation reduces cross-context ambiguity under the assumed hash properties; it does not make collisions impossible.
Transaction identifiers
A transaction identifier, or txid, is the double SHA-256 of the transaction’s legacy serialization without witness data. Bitcoin Core computes it with TX_NO_WITNESS.
A witness transaction identifier, or wtxid, is the double SHA-256 of the witness-inclusive serialization when witness data exists. For a transaction without witness data, Bitcoin Core defines the wtxid to equal the txid.
The byte sequence fed to the hash is serialized in protocol order. Human-facing software commonly displays the internal 32-byte value with reversed byte order, so a hex string seen in a block explorer may appear reversed relative to bytes in a serialized outpoint.
This display convention does not change the hash function. It is an endianness and presentation issue. Documentation should identify whether it is showing wire bytes, an internal integer representation, or the conventional displayed identifier.
A transaction signature hash is not a txid. Signature messages select and transform transaction fields under sighash rules. Two 32-byte digests can serve entirely different protocol roles.
Block identifiers and proof of work
A Bitcoin block header contains:
- version;
- previous-block hash;
- transaction Merkle root;
- time;
- encoded target in
nBits; - nonce.
The serialized 80-byte header is double-SHA-256 hashed. The resulting 256-bit value is interpreted as a number for proof-of-work comparison. A header is valid under the proof-of-work rule when its value is less than or equal to the target derived from nBits, subject to the other block and chain rules.
The commonly displayed block hash is the same digest presented in conventional reversed-byte hex notation. The proof-of-work comparison operates on the defined numeric interpretation, not on the visual number of leading zero characters alone.
Mining is repeated hashing, not decryption
Miners assemble candidate block headers and vary fields such as the nonce, extra nonce in the coinbase transaction, time within allowed rules, and transaction selection. Each change can alter the Merkle root or header. Mining hardware repeatedly computes double SHA-256 and checks whether the output meets the current target.
There is no encrypted message to decrypt and no secret plaintext to recover. Miners are not reversing SHA-256. They are sampling candidate headers until one produces a sufficiently low output.
Because hash outputs are modeled as unpredictable, each validly constructed attempt behaves like another trial. Finding a block does not reveal how to shortcut the next search.
Targets and difficulty
The target is a 256-bit threshold. A lower target makes qualifying hashes rarer. The compact nBits field encodes the target in the block header.
“Difficulty” is a human-facing ratio comparing a reference target to the current target. Bitcoin consensus validates the target and the block hash under exact chain rules; software and websites may present difficulty using different numeric precision or formatting.
The network periodically adjusts the target according to consensus rules. Hash rate is an estimate inferred from observed block production and target, not a field recorded directly in each block.
These distinctions matter because a block hash, target, difficulty, and estimated hash rate are different quantities even though all are discussed in mining explanations.
Merkle-tree hashing
The transaction Merkle tree uses transaction identifiers as leaves. At each level, adjacent 32-byte values are concatenated in the algorithm’s internal byte order and double-SHA-256 hashed to create a parent.
When a level has an odd number of nodes, Bitcoin duplicates the final node before hashing the pair. This historical rule contributes to a known mutation ambiguity and is not a general recommendation for new Merkle designs.
The witness Merkle tree similarly uses wtxid values, with a zero leaf for the coinbase transaction. Taproot script trees use different tagged leaf and branch hashes. “The Merkle hash” is therefore not one universal construction in Bitcoin.
Script hash commitments
Different output types commit to scripts or keys differently:
- P2PKH: HASH160 of a public key.
- P2SH: HASH160 of a redeem script.
- P2WPKH: HASH160 of a compressed public key.
- P2WSH: SHA-256 of a witness script.
- P2TR: 32-byte x-only output key, which may be tweaked by a tagged hash committing to a Taproot script-tree root.
A hash commitment does not itself prove that a party knows a preimage or controls a key. Script execution requires the spender to reveal or satisfy the data expected by the output program.
Taproot commitments
Taproot combines an internal x-only public key with an optional script-tree root through the tagged TapTweak hash. The tweak modifies the output key. A key-path signature is checked under the tweaked output key.
A script-path spend reveals a tapscript leaf, leaf version, control block, and the necessary branch hashes. The verifier recomputes:
- the tagged
TapLeafhash from the leaf version and serialized script; - each tagged
TapBranchparent after lexicographically ordering the two child hashes; - the tweak and output key;
- the parity and internal-key relationship carried by the control block.
Taproot’s branch ordering and tagged leaf encoding differ from the block transaction Merkle tree. They should not be described as the same hash tree with different data.
Hashlocks
A hashlock is a script condition that requires a spender to reveal a preimage whose hash matches a committed digest. Bitcoin Script includes operations such as OP_SHA256, OP_HASH160, and related hash opcodes.
A typical construction commits to H(x) and later reveals x. This supports conditional protocols such as atomic-swap and payment-channel designs when combined with signatures and time locks.
A hashlock proves only that the spending witness supplied a preimage satisfying the script. It does not prove who originally chose the secret, keep the secret private after publication, or make the broader protocol safe.
Commit-and-reveal patterns
Hash commitments can separate a commitment phase from a later reveal phase. The committing party publishes a digest; later it reveals the data so others can recompute the hash.
A secure commitment design may require:
- domain separation;
- unambiguous serialization;
- sufficient secret entropy;
- a salt or nonce;
- binding to context, participants, and version;
- a clear reveal and timeout process.
Hashing a predictable answer without a salt can allow brute-force guessing. Hashing concatenated fields without lengths or a canonical encoding can create ambiguity even when the hash function itself behaves correctly.
Base58Check
Legacy Bitcoin addresses and several key encodings use Base58Check. The encoded payload includes a version or type prefix and data. The checksum is the first four bytes of double SHA-256 applied to that payload.
This 32-bit checksum helps detect many transcription errors. It is not a cryptographic proof of ownership, authorization, or authenticity. An attacker can construct a different payload with its own valid checksum, and a maliciously substituted valid address will pass checksum verification.
A sender must still verify the intended recipient and network. “The checksum is valid” means only that the string is internally consistent under the encoding.
Bech32 and Bech32m
BIP 173 defines Bech32 for version 0 witness addresses. Its six-character checksum uses a BCH-code-derived polymod calculation over the human-readable part and data symbols. It is not SHA-256.
BIP 350 defines Bech32m by changing the final checksum constant. Version 0 witness programs continue to use Bech32. Witness versions 1 through 16, including Taproot’s version 1, use Bech32m.
A decoder must check both the checksum and the expected encoding for the witness version. Accepting a valid Bech32 string where Bech32m is required, or vice versa, is an error.
Bech32 and Bech32m checksums are designed to detect common character errors. They do not prove that the witness program belongs to a specific person, that it is spendable, or that the recipient generated it.
Length extension
SHA-256 follows a Merkle–Damgård construction. If a protocol uses a raw digest as though it authenticated secret || message, length-extension behavior can matter: knowledge of the digest and message length may allow computing a digest for a padded extension without learning the secret.
This does not mean every direct use of SHA-256 in Bitcoin is vulnerable. Many Bitcoin constructions hash public serialized data, use fixed lengths, double hash, use HMAC-like designs, or apply tagged hashes with committed structure.
The correct lesson is to analyze the full construction. “Single SHA-256 is unsafe” and “double SHA-256 fixes everything” are both misleading.
Collision language and protocol consequences
A discovered collision in one context does not automatically spend coins. Consequences depend on what the attacker can choose and what the digest commits to.
For example:
- A collision in an address checksum is not a private-key break.
- A collision in a script commitment would still need to satisfy the exact output and script context.
- A transaction-identifier collision could affect indexing and commitments differently from a preimage attack on an existing transaction.
- A break in signature-hash collision resistance must be analyzed with the signature scheme and attacker control of messages.
This is why source notes should identify whether a claim depends on preimage, second-preimage, collision, or pseudorandom-output behavior.
Quantum-computing boundaries
Grover’s algorithm gives a theoretical quadratic speedup for generic preimage search. In an idealized model, that changes a 256-bit preimage search scale toward roughly 2^128 quantum operations, while collision search and real implementations require more nuanced analysis.
That does not imply a practical current attack on Bitcoin’s hash functions. Fault-tolerant quantum resources, circuit depth, error correction, parallelism, and target-specific constraints matter. Hash functions are also affected differently from secp256k1 signatures, for which Shor’s algorithm targets the discrete-log assumption.
Bitcoin’s deployed rules do not automatically upgrade if technology changes. Any response would require evidence, software, wallet behavior, and potentially consensus coordination. Timelines should not be invented.
Current confidence and version-sensitive claims
As of the evidence reviewed July 25, 2026, Bitcoin Core 31.1 continues to implement SHA-256, double SHA-256, HASH160, tagged hashes, the established identifier constructions, proof-of-work checks, address decoders, and script hash operations described here.
That is an implementation and deployment statement, not an eternal cryptographic guarantee. New cryptanalysis, standards changes, consensus proposals, or implementation defects could alter an assessment. Claims about “security bits,” quantum implications, or address safety should state their assumptions and date.
A hash-construction checklist
When reading or writing a Bitcoin hash claim, ask:
- What exact bytes are serialized?
- Which hash function or checksum algorithm is used?
- Is it applied once, twice, or as part of HASH160 or a tagged construction?
- What is the output length?
- Is the goal identification, commitment, proof of work, error detection, or signature-message construction?
- Does the claim depend on preimage, second-preimage, or collision resistance?
- Is the value shown in internal byte order or conventional displayed order?
- Does a checksum merely detect errors, or is a script/signature check also required?
- Is the statement about consensus, Bitcoin Core 31.1, a wallet, or an application?
Bitcoin’s hash functions are best understood as a set of precise components, not one universal “hashing layer.”