SHA256 in Blockchain: How It Works

Why Bitcoin Chose SHA256

Satoshi Nakamoto chose SHA256 as Bitcoin's core hash function because: SHA256 was already widely adopted and thoroughly audited by NIST, with strong collision resistance and one-way properties; SHA256's output is uniformly distributed, ideal as a proof-of-work target; SHA256 is efficient in hardware implementation (specialized SHA256 ASIC mining machines were indeed developed later); and SHA256's 256-bit output provides sufficient security margin for the foreseeable future.

Proof of Work (PoW): SHA256's Core Use

Bitcoin's proof of work mechanism is SHA256's most important application: miners need to find a nonce so that the double SHA256 hash (SHA256(SHA256(block_header))) of the block header is less than the current difficulty target. The difficulty target requires the hash to start with a certain number of zeros, for example:

/* Block header structure */
version: 4 bytes
previous_block_hash: 32 bytes (SHA256 hash!)
merkle_root: 32 bytes (SHA256 hash of all transactions!)
timestamp: 4 bytes
difficulty_bits: 4 bytes
nonce: 4 bytes (miner changes this!)

/* Mining goal */
SHA256(SHA256(block_header)) must start with N zeros:
0000000000000000000329827...  (many leading zeros)

/* Miner tries billions of nonce values until one works */

How SHA256 Links Blocks Together

The blockchain is "chained" precisely because each block header contains the SHA256 hash of the previous block header (Previous Block Hash). If anyone tries to modify any data in a historical block, that block's hash changes, causing the Previous Block Hash recorded in the next block to no longer match, which makes the entire chain's hash verification fail. This is why blockchain is difficult to tamper with — modifying history requires re-mining all subsequent blocks from the modified block onward.

Transaction IDs and Merkle Trees

Every Bitcoin transaction has a TXID (transaction ID), which is the result of double SHA256 hashing the transaction data. All TXIDs in a block are aggregated through a Merkle tree structure: pairs are hashed together repeatedly until a single Merkle Root hash is obtained, which is included in the block header.

/* Merkle tree structure (simplified) */
Transactions: T1, T2, T3, T4

Leaf hashes:
H1 = SHA256(SHA256(T1))
H2 = SHA256(SHA256(T2))
H3 = SHA256(SHA256(T3))
H4 = SHA256(SHA256(T4))

Level 2:
H12 = SHA256(SHA256(H1 + H2))
H34 = SHA256(SHA256(H3 + H4))

Merkle Root:
Root = SHA256(SHA256(H12 + H34))

Bitcoin Address Generation and SHA256

Bitcoin address generation also extensively uses SHA256: from private key (random number) → public key (elliptic curve point multiplication) → SHA256(public key) → RIPEMD-160(above result) = public key hash (160 bits) → add version byte → SHA256(SHA256(with version byte)), take first 4 bytes as checksum → Base58 encoding = Bitcoin address. This process uses a combination of SHA256, RIPEMD-160, and Base58, called HASH160 and HASH256.

Ethereum Uses Keccak-256, Not SHA256

Notably, Ethereum chose Keccak-256 rather than SHA256. Keccak-256 is the original proposal version of the SHA-3 standard (NIST made minor modifications during standardization, so Ethereum's Keccak-256 is not exactly the same as SHA3-256). Ethereum's address generation, transaction hashes, etc. all use Keccak-256. In Web3 development, this is an easily confused detail — call keccak256() not sha256().

SHA256 in Other Blockchains

Beyond Bitcoin, many other blockchains and related systems use SHA256: Bitcoin Cash, Bitcoin SV, and other Bitcoin forks; most proof-of-work algorithms (Litecoin's Scrypt also uses SHA256); IPFS content identifiers (CIDs) use SHA256; SSL/TLS certificate chain hashes. SHA256 became the de facto blockchain hash standard due to over twenty years of cryptographic auditing without practical vulnerabilities being discovered.