Timechain Wiki

SHA-256

11 min read

SHA-256 is the cryptographic hash function Bitcoin uses for nearly every hashing operation: block hashes, transaction IDs, Merkle tree construction, address derivation, the Proof of Work puzzle itself. It takes input of arbitrary length and produces a 256-bit output deterministically, fast to compute forward, computationally infeasible to reverse. Three properties define a cryptographic hash function: preimage resistance, second-preimage resistance, and collision resistance — Bitcoin's security depends on all three, especially the last. SHA-256 was specified by NIST in 2001 (FIPS 180-2) as part of the SHA-2 family and remains unbroken. Bitcoin frequently applies SHA-256 twice in succession — the "double-SHA-256" or "HASH256" convention — for length-extension-attack resistance.

Why this note matters

SHA-256 is the second foundational primitive Bitcoin depends on, alongside public-key cryptography (see Public key cryptography). Where public-key cryptography is the authorization primitive (who can sign), SHA-256 is the commitment primitive (what was committed to). Every Bitcoin operation that needs a stable, unforgeable reference to data — block hashes, transaction IDs, Merkle roots, address commitments — uses SHA-256.

Proof of Work itself is essentially a search for an input whose SHA-256 hash falls below a target threshold. The entire energy expenditure of Bitcoin mining is, mechanically, repeated SHA-256 computation. If SHA-256 were broken — if collisions became cheap, or preimages reversible — Bitcoin’s security would collapse in multiple ways simultaneously. As of 2026, no significant cryptanalytic attack on SHA-256 exists; the function has held up across 25 years of intense scrutiny.

What a cryptographic hash function is

A hash function maps inputs of arbitrary length to outputs of fixed length. Familiar non-cryptographic examples include CRC32 (used for error-detection in network protocols) and the hash functions backing common hash-table data structures. A cryptographic hash function adds three security-relevant properties:

  • Preimage resistance. Given an output h, finding any input x such that H(x) = h is computationally infeasible. The function is “one-way.”
  • Second-preimage resistance. Given an input x₁, finding a different input x₂ ≠ x₁ such that H(x₂) = H(x₁) is computationally infeasible.
  • Collision resistance. Finding any pair of distinct inputs x₁, x₂ such that H(x₁) = H(x₂) is computationally infeasible.

Collision resistance is the strongest of the three; collision resistance implies second-preimage resistance, which in turn implies preimage resistance (for most realistic input distributions).

Additionally, a good cryptographic hash function exhibits:

  • Avalanche. A single-bit change in input flips roughly half the output bits.
  • Determinism. Same input always produces same output.
  • Uniformity. Outputs distribute approximately uniformly over the output space.

SHA-256 satisfies all of these. The function is fast in software (gigabytes per second on commodity hardware), has been subjected to 25 years of cryptanalysis without significant weaknesses found, and is hardware-accelerated on most modern CPUs.

SHA-256 specifically

SHA-256 is part of the SHA-2 family standardized by NIST in 2001 (FIPS 180-2). The family includes SHA-224, SHA-256, SHA-384, and SHA-512 — variants differing in output length and internal block size. SHA-256 specifically produces a 256-bit output (32 bytes, expressible as 64 hex characters).

For black-box purposes, the inner construction (the Merkle-Damgård structure, the compression function, the 64-round permutation over 32-bit words) does not matter for understanding Bitcoin’s use of SHA-256. What matters is the input/output contract:

  • Input: any byte string, any length
  • Output: exactly 32 bytes
  • Behavior: deterministic; fast; one-way; collision-resistant

Worth knowing for context: SHA-256 inherits from SHA-1 (its predecessor in the SHA family). SHA-1 was broken in 2017 by Google’s SHAttered attack, which produced an explicit collision. SHA-256 is a different design with different internals and substantially larger output — the SHA-1 break does not transfer.

Where Bitcoin uses SHA-256

The function appears at many layers of the protocol. Worth cataloging:

  • Proof of Work. Miners search for a nonce such that the SHA-256 hash of the block header (double-applied) falls below the current difficulty target. The bulk of Bitcoin’s energy expenditure is SHA-256 computation. See Proof of Work.
  • Block hashes. The unique identifier of a block is the double-SHA-256 of its 80-byte header. The chain of blocks is literally a chain of hashes referencing prior hashes.
  • Transaction IDs (txids). A transaction’s identifier is the double-SHA-256 of its serialized form (in pre-SegWit format) or its non-witness serialization (post-SegWit, to avoid malleability). See UTXO model and Bitcoin transactions.
  • Merkle root construction. Each block contains a Merkle root summarizing all transactions in the block; the tree is built by iteratively double-SHA-256-hashing pairs of nodes. See Merkle trees.
  • Address derivation. Bitcoin addresses use HASH160, which is RIPEMD160(SHA-256(public_key)). The intermediate SHA-256 step shortens 33-byte compressed public keys before the final 20-byte RIPEMD160 step. See Bitcoin addresses.
  • P2SH / P2WSH script commitment. Pay-to-Script-Hash and Pay-to-Witness-Script-Hash output types commit to a script via its (HASH160 or SHA-256) hash; the actual script is revealed only at spend time. See Bitcoin Script and opcodes.
  • Script-layer hashing opcodes. OP_SHA256 (single SHA-256), OP_HASH256 (double SHA-256), and OP_HASH160 (SHA-256 followed by RIPEMD160) are available within Bitcoin Script for in-script hash commitments — used for HTLC (Hash Time-Locked Contract) constructions and Lightning payment channels.
  • Taproot tweaks. BIP-341 Taproot uses tagged hashes (a SHA-256 construction with a domain-separation prefix) for committing the script tree to the output key.
  • BIP-32 hierarchical derivation. HD wallet child-key derivation uses HMAC-SHA-512 (a SHA-2 family construction); SHA-256 itself appears in adjacent BIP-32 hashing operations.

In aggregate: every layer of Bitcoin that needs a tamper-evident commitment to data uses SHA-256.

The double-SHA-256 convention

Bitcoin frequently applies SHA-256 twice in succession, written SHA256(SHA256(x)) or HASH256(x). This is the standard convention for block hashes, transaction IDs, and Merkle nodes.

Why double-hash? The reason traces to length-extension attacks. SHA-256 (like SHA-1 before it) uses the Merkle-Damgård construction internally, which makes it vulnerable to a specific attack: given H(x) and the length of x, an attacker can compute H(x || padding || y) for any y of their choosing, without knowing x. This is a problem in some message-authentication protocols.

Applying SHA-256 twice — feeding the output of the first SHA-256 as the input to a second SHA-256 — disrupts length-extension because the second invocation processes a fixed-length 32-byte input. The attack does not extend through the second hash.

Whether Bitcoin actually needs this defense in every place it uses double-SHA-256 is debatable — many double-SHA-256 sites in Bitcoin don’t have length-extension exposure even with single-SHA-256. The convention is now entrenched and is the standard form.

Modern Bitcoin protocol additions (BIP-340 Schnorr, BIP-341 Taproot) use tagged hashes instead — SHA256(SHA256(tag) || SHA256(tag) || message) — which provides domain separation between hashing contexts. This is a cleaner construction than the legacy double-hash.

Why SHA-256 specifically

Satoshi chose SHA-256 in 2008 from a small set of practical alternatives. The relevant considerations:

  • Standardized and well-vetted. SHA-256 was NIST-standardized in 2001 and had seven years of cryptanalysis when Bitcoin launched. No serious attacks were known then or have emerged since.
  • 256-bit output size. Matches the security level of secp256k1 (~128 bits classical security). Mixing primitives with substantially different security levels would be inefficient — the weakest link determines overall strength.
  • Fast in software and hardware. SHA-256 is computationally cheap; nodes can verify transactions and blocks at high throughput on commodity hardware.
  • No patent restrictions. SHA-2 family is unencumbered by patents.

Why not SHA-3? SHA-3 (Keccak) was selected by NIST as the next-generation standard in 2012, four years after Bitcoin’s launch. By the time SHA-3 was available, SHA-256 was already entrenched throughout the Bitcoin protocol; switching would have required a hard fork.

Why not BLAKE2 / BLAKE3? These hash functions are faster than SHA-256 and considered cryptographically sound. They were not available in 2008. Even now, the cost of switching (a hard fork affecting every block, transaction, and address) vastly outweighs the marginal speed gain.

The choice has held up. SHA-256 remains unbroken; no proposed migration is on the horizon.

Tradeoffs and design choices

ASIC-friendliness. SHA-256 was designed for software efficiency on general-purpose CPUs. Within a few years of Bitcoin’s launch, dedicated ASIC (application-specific integrated circuit) hardware emerged that computes SHA-256 orders of magnitude more efficiently than CPUs or GPUs. This shifted Bitcoin mining from hobbyist computers (2009-2010) to GPU farms (2011-2012) to ASIC operations (2013 onward). The substantive concerns around mining centralization that follow from this evolution live in Mining centralization concerns (Criticisms section).

Was ASIC-resistance an option? A few altcoins (Litecoin with scrypt; Monero with RandomX; many others) chose memory-hard or otherwise ASIC-resistant hash functions specifically to keep mining on commodity hardware. The empirical record is mixed: ASIC-resistance has generally delayed, not prevented, specialized hardware emergence. Bitcoin’s choice (SHA-256, ASIC-accepting) prioritized security and standardization over mining decentralization through hardware-class. Reasonable people disagree on whether this tradeoff was correct.

Quantum threat (Grover’s algorithm). A cryptographically relevant quantum computer running Grover’s algorithm can speed up hash preimage search by a quadratic factor — finding an SHA-256 preimage in ~2^128 operations instead of the classical ~2^256. This reduces SHA-256’s preimage security from 256 bits to 128 bits. Importantly: 128-bit security is still considered cryptographically sound in the foreseeable quantum future. Hash-based commitments survive the quantum threat far better than public-key cryptography does. Substantive engagement in Quantum computing threat to Bitcoin (Criticisms section).

Length-extension attacks. SHA-256 is vulnerable to length-extension by virtue of its Merkle-Damgård construction. The double-SHA-256 convention mitigates this; tagged hashes (used in Taproot) provide a cleaner solution.

No structural backdoors known. SHA-256’s design (Merkle-Damgård + compression function + standardized constants) has been heavily scrutinized. Unlike the Dual_EC_DRBG random-number-generator incident, no plausible backdoor in SHA-256 has been identified. The constants used in SHA-256 are explainable (fractional parts of cube roots of primes); they were not chosen opaquely.

Open questions for further development

  • What is the expected timeline for SHA-256’s eventual cryptographic obsolescence? Estimates vary widely but most cryptographers consider the function sound for at least the next several decades absent unforeseen attacks.
  • If post-quantum signature schemes require larger hash function output sizes (some proposed schemes use SHA-512 or SHA-3-512 for security), does Bitcoin migrate hash function alongside signature scheme, or piecemeal?
  • What is the threshold for “cryptographically relevant” quantum computing in the SHA-256 context (Grover’s algorithm)? The crossover at which classical attacks become slower than quantum ones is well-understood theoretically but operationally unclear.
  • How does the ASIC-mining-monoculture risk evolve? If a single ASIC manufacturer captures a supermajority of hardware production, does the hash function choice become a centralization vector? See Mining centralization concerns for the analytical engagement.

Canonical sources for this note

Standards documents

  • FIPS 180-4 — NIST’s Secure Hash Standard, the official specification of SHA-256 and the rest of the SHA-2 family. Free at nist.gov.
  • RFC 6234 — US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) — implementation-friendly specification.

Bitcoin engineering references

  • Mastering Bitcoin, Andreas Antonopoulos (chapter 7: “The Blockchain”, chapter 12: “Mining”) — treatment of how SHA-256 functions across Bitcoin’s layers. See Mastering Bitcoin - Andreas Antonopoulos.
  • Programming Bitcoin, Jimmy Song (chapter 4: “Serialization”, chapter 9: “Blocks”) — working-programmer treatment of double-SHA-256 use in transaction and block serialization.

Cryptographic foundations (for the textbook depth this note defers)

  • Handbook of Applied Cryptography, Menezes, van Oorschot, and Vanstone (chapter 9: “Hash Functions and Data Integrity”) — the standard reference.
  • Cryptographic Hash Functions survey literature — e.g., the SHA-3 competition documentation, which discusses SHA-2’s properties as the comparison point.

Quantum-threat research

  • Bitcoin & Quantum Computing, NVK (Rodolfo Novak) research series at bitcoinquantum.space — covers Grover’s algorithm impact on SHA-256 hashing. See Rodolfo Novak.
  • Public key cryptography — The companion foundational primitive; public-key operations often feed into SHA-256 for address derivation.
  • Merkle trees — Built directly on SHA-256; every internal node is a SHA-256 hash of its two children.
  • Signature schemes in Bitcoin — Signatures are computed over SHA-256 hashes of transaction data; the signing context uses tagged-hash variants in Taproot.
  • Bitcoin addresses — HASH160 (RIPEMD160 over SHA-256 of public key) for legacy addresses; SHA-256 inside Bech32 / Bech32m checksums.
  • UTXO model and Bitcoin transactions — Transaction IDs are double-SHA-256 of serialized transactions.
  • Blocks and the blockchain — Block headers are identified by their double-SHA-256 hash; the chain structure is a sequence of hash pointers.
  • Proof of Work — The core mining operation is SHA-256 hash search; the bulk of Bitcoin’s energy expenditure is SHA-256 computation.
  • Quantum computing threat to Bitcoin — Engagement with Grover’s-algorithm impact on hash function security. Criticisms section.
  • Mining centralization concerns — ASIC-monoculture concerns that follow from SHA-256’s ASIC-friendliness. Criticisms section.

Graph View

Backlinks