What is a Cryptographic Hash in the Context of Blockchain?

What is a Cryptographic Hash in the Context of Blockchain?

Cryptographic hashes are the quiet workhorses of blockchains. They compress arbitrary-length data (a transaction, a block header, even an entire file) into a fixed-size “fingerprint” called a hash. Change even a single bit of the input, and the output hash changes unpredictably. This simple idea—done with precisely designed algorithms—enables blockchains to be tamper-evident, efficiently verifiable, and decentralized at global scale. (NIST Computer Security Resource Center)

---

TL;DR (Key Takeaways)

• A cryptographic hash function maps data of any length to a fixed-length digest and is expected to provide preimage, second-preimage, and collision resistance. These properties are formalized by NIST and are the bedrock of blockchain security. (NIST Computer Security Resource Center)
• Bitcoin relies heavily on SHA-256 (often double SHA-256) for block hashing, transaction IDs, and checksums; Ethereum relies on Keccak-256 (closely related to, but not identical with, NIST’s SHA-3). (NIST Publications)
• Hashes “chain” blocks together via hash pointers and compress many transactions into a single Merkle root, allowing light clients (SPV) to verify transactions without downloading the entire chain. (assets.press.princeton.edu)

---

1) What is a Cryptographic Hash?

Formally, a cryptographic hash function takes an input of arbitrary (bounded) length and returns a fixed-length output (e.g., 256 bits). It must be:

• Preimage-resistant: given a hash h, it’s computationally infeasible to find any input x such that hash(x) = h.
• Second-preimage-resistant: given x, it’s infeasible to find a different x’ with the same hash.
• Collision-resistant: it’s infeasible to find any x and x’ (x ≠ x’) with the same hash. (NIST Computer Security Resource Center)

These aren’t just “nice to have” features; they are the reason blockchains can expose adversarial participants to detection whenever data is tampered with.

---

2) How Does a Hash Look in Practice?

Feed any input—say a JSON transaction or a block header—into SHA-256 and you get a 32-byte digest. Flip one bit in the input, and the output changes dramatically (the avalanche effect). This unpredictability lets nodes quickly detect unauthorized changes: recompute the hash and compare.

In standardization terms, SHA-2 functions (including SHA-256) are defined by FIPS 180-4; the SHA-3 family (based on the Keccak sponge construction) is defined by FIPS 202. (NIST Publications)

---

3) Why Hashes Matter So Much for Blockchains

3.1 Hash Pointers: Linking Blocks into a “Chain”

Each block header stores the hash of the previous block header—a hash pointer. Any change in a prior block changes its header hash, breaking all subsequent pointers. This makes past edits tamper-evident: to rewrite history, an attacker would need to recompute a vast number of hashes (and, in proof-of-work systems, redo the associated work). (assets.press.princeton.edu)

3.2 Merkle Trees: Compressing Many Transactions into One Root

Inside a block, transactions are hashed pairwise up a Merkle tree until a single Merkle root remains. The root goes into the block header. With just the root and a short “Merkle proof,” light clients can verify a transaction’s inclusion without downloading the whole block—core to Bitcoin’s simplified payment verification (SPV). (Investopedia)

3.3 Proof-of-Work: Turning Hashing into Consensus

Bitcoin turns hashing into proof-of-work (PoW): miners repeatedly vary a nonce in the block header and compute the double SHA-256 of that header until the result is below a difficulty target. This is hard to find but trivial to verify—just recompute the hash once. (Bitcoin)

---

4) Which Hash Algorithms Do Major Chains Use?

• Bitcoin: SHA-256 (often double SHA-256). The algorithm family and operations are covered by FIPS 180-4; the PoW description is in the Bitcoin whitepaper. Double SHA-256 is widely referenced in Bitcoin docs and BIPs, used both for block hashing and checksums (e.g., Base58Check). (NIST Publications)
• Ethereum: Keccak-256, which is the pre-standardization variant upon which SHA-3 is based. Ethereum’s Yellow Paper specifies Keccak-256 for block fields and tries; addresses are derived from the last 20 bytes of the Keccak-256 of the public key. (Important nuance: Keccak-256 ≠ FIPS-202 SHA-3-256 due to padding differences.) (ethereum.github.io)

Standards note: NIST maintains both SHA-2 (FIPS 180-4) and SHA-3 (FIPS 202). It does not deprecate SHA-2; SHA-3 is a different family added to the toolkit. (NIST)

---

5) Bitcoin Examples: Hashes in Addresses, IDs, and Checksums

• Transaction IDs / Block IDs: conventionally the (double) SHA-256 of serialization formats. (Bitcoin)
• Legacy (P2PKH) addresses: RIPEMD-160(SHA-256(public-key)), often written HASH160; a checksum using double SHA-256 of the payload is appended before Base58 encoding (Base58Check). This makes addresses shorter and resilient to typos. (Bitcoin Developer Documentation)
• Base58Check details: the checksum is the first 4 bytes of SHA256(SHA256(version || payload)). (Bitcoin Cash Documentation)

This layered use of different hash functions (SHA-256 and RIPEMD-160) balances security and address length, while Base58Check’s checksum catches common transcription errors. (Bitcoin Developer Documentation)

---

6) Ethereum Examples: Keccak-256 Everywhere

Ethereum uses Keccak-256 for:

• Block header fields (e.g., parentHash, stateRoot, transactionsRoot, receiptsRoot).
• Address derivation: last 20 bytes of keccak256(publicKey).
• Contract creation (CREATE): contract address is last 20 bytes of keccak256( RLP(sender, nonce) ). (ethereum.github.io)

Because Keccak-256 differs slightly from SHA-3-256 (padding), Ethereum clients and tooling consistently implement the Keccak variant noted in the Yellow Paper. (Ethereum Stack Exchange)

---

7) Security Properties in Practice

NIST guidance emphasizes that the security strength of a hash depends on which property your application relies on (preimage, second-preimage, collision) and the digest length. For many applications, 256-bit digests provide strong security margins today. (NIST CSRC)

• Preimage resistance underpins “one-wayness”: you can’t recover inputs from outputs.
• Collision resistance matters for signatures and identifiers: you shouldn’t be able to find two different blocks or transactions with the same ID.
• Second-preimage resistance prevents swapping one valid message for another with the same hash.

Legacy hashes like MD5 and SHA-1 are considered broken or deprecated for collision resistance, hence their absence in modern blockchain designs. (By contrast, Bitcoin and Ethereum rely on SHA-2/Keccak families, respectively, per the standards and specs above.) (NIST Publications)

On sensational claims: Occasionally, companies claim breakthroughs in “cracking Bitcoin” or predicting hashes. Such claims consistently face skepticism because they would require violating well-studied properties of SHA-256/Keccak; absent reproducible evidence, the crypto community treats them cautiously. (Financial Times)

---

8) How Hashes Enable Immutability and Efficiency

• Immutability via linkage: tampering with block n alters its header hash, which invalidates block n+1’s prevHash, and so on. A full node detects the mismatch immediately. (assets.press.princeton.edu)
• Fast verification via Merkle proofs: to prove a transaction is in a block, you only provide O(log N) sibling hashes to reconstruct the Merkle root; if the computed root matches the header, inclusion is proven. (Investopedia)
• Consensus via PoW: because target thresholds are tiny relative to the output space, finding a valid hash is probabilistic and energy-constrained, but verifying it is cheap—just recompute the double hash once. (Bitcoin)

---

9) Developer Corner: Common Gotchas

• Double hashing (Bitcoin): Many resources and libraries assume double SHA-256 for IDs and checksums—be explicit about whether you need single or double hashing. (Bitcoin Wiki)
• Bytes vs hex: Hash functions operate on bytes, not the human-readable hex string. Convert appropriately to avoid subtle bugs. (Stack Overflow)
• Keccak vs SHA-3: In Ethereum land, use Keccak-256 (the “winning entry” variant), not FIPS-202 SHA-3-256—outputs differ. (Ethereum Stack Exchange)
• Endianness and serialization: Bitcoin serializations (e.g., block headers) have specific field ordering and little-/big-endian quirks; always follow the canonical spec or a battle-tested library. (NIST Publications)

---

10) Real-World Workflow Examples

Example A: Verifying a Transaction’s Inclusion (SPV)

1. Obtain the transaction hash (typically double SHA-256 in Bitcoin).
2. Get the Merkle proof (sibling hashes up to the root).
3. Recompute the root and compare to the header’s Merkle root. If they match, the tx is included in that block—no need for the full block data. (Investopedia)

Example B: Generating a Bitcoin Legacy Address (Conceptually)

1. Start with an ECDSA public key.
2. Compute HASH160 = RIPEMD-160(SHA-256(pubkey)).
3. Prepend version byte, then append double-SHA-256 checksum’s first 4 bytes.
4. Base58 encode → address. (Bitcoin Developer Documentation)

Example C: Deriving an Ethereum Address

1. Take the uncompressed public key (64 bytes).
2. Compute Keccak-256 of it; take the last 20 bytes → the address. (Prefix 0x when displayed.) (Ethereum Stack Exchange)

---

11) Frequently Asked Questions

Q1) Are SHA-256 and SHA-3 interchangeable?
Not exactly. SHA-256 is part of SHA-2 (FIPS 180-4). SHA-3 is a different family (FIPS 202) based on a sponge permutation (Keccak). Ethereum uses Keccak-256, which differs slightly from SHA-3-256 due to padding—so hashes won’t match between the two. (NIST Publications)

Q2) Can I reverse a hash to get the original data?
No—hashes are designed to be one-way (preimage-resistant). The only generic approach is brute force, which is computationally infeasible for well-chosen algorithms and input sizes. (NIST Computer Security Resource Center)

Q3) Why does Bitcoin “double hash” some things?
Double SHA-256 helps mitigate certain structural attacks (e.g., length-extension) and became part of early design practice. It’s also entrenched in tooling, docs, and wire formats (e.g., Base58Check checksums). (Bitcoin Wiki)

Q4) What’s the role of hashes in consensus after Ethereum’s merge (PoS)?
Even without PoW, Ethereum’s block structure, tries, and receipts still rely on Keccak-256 to authenticate state and transactions. The consensus mechanism changed; the integrity layer (hashing) did not. (ethereum.github.io)

---

12) Best Practices for Builders

• Stick to NIST-approved primitives and well-maintained libraries; avoid “homegrown crypto.” Use SHA-256/SHA-512 for Bitcoin-style systems; use Keccak-256 for Ethereum-compatible stacks. (NIST Publications)
• Be precise about the variant (Keccak-256 vs SHA-3-256) and about single vs double hashing. (Ethereum Stack Exchange)
• Validate encodings and endianness when reproducing on-chain hashes off-chain (e.g., for explorers or indexers). (NIST Publications)
• Use Merkle/Patricia structures where appropriate to enable efficient proofs and light-client verification. (Ethereum’s Yellow Paper specifies Keccak-256 roots for state/transactions/receipts.) (ethereum.github.io)

---

13) Conclusion

In blockchains, cryptographic hashing is both the glue (linking blocks, binding transactions into roots) and the gatekeeper (proof-of-work puzzles, address checksums). The field’s maturity—reflected in standards like FIPS 180-4 (SHA-2) and FIPS 202 (SHA-3)—gives builders robust, well-analyzed primitives. Whether you’re verifying a Merkle proof, deriving an address, or validating a block header, you are leaning on hash functions’ rigorously defined properties to keep decentralized ledgers trustworthy. (NIST Publications)

---

Sources & Further Reading

• NIST Glossary & Recommendations
  • NIST Glossary definition of (cryptographic) hash functions and required properties. (NIST Computer Security Resource Center)
  • SP 800-107 Rev.1 – Recommendation for Applications Using Approved Hash Functions (discussion of preimage/second-preimage/collision strength). (NIST Publications)
  • FIPS 180-4 – Secure Hash Standard (SHA-1, SHA-224/256/384/512). (NIST Publications)
  • FIPS 202 – SHA-3 Standard (Keccak-based). (NIST Publications)
• Bitcoin (SHA-256) Resources
  • S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (PoW via finding a SHA-256 hash under target). (Bitcoin)
  • Bitcoin developer reference: P2PKH uses RIPEMD-160(SHA-256(pubkey)); Base58Check uses a double-SHA-256 checksum. (Bitcoin Developer Documentation)
• Ethereum (Keccak-256) Resources
  • Ethereum Yellow Paper (Keccak-256 for block fields and tries). (ethereum.github.io)
  • Address derivation from public key using Keccak-256 (last 20 bytes). (Ethereum Stack Exchange)
• Data Structures & Proofs
  • Narayanan et al., Bitcoin and Cryptocurrency Technologies (hash pointers; tamper-evident logs). (assets.press.princeton.edu)
  • Investopedia explainer on Merkle trees (use in Bitcoin and benefits for verification). (Investopedia)

---

(Optional) Glossary

• Hash / Digest: The fixed-length output of a hash function.
• Merkle Tree / Root: A binary tree of hashes culminating in a single root that commits to all leaves (transactions). (Investopedia)
• Hash Pointer: A pointer to data plus the hash of that data; used to link blocks, making tampering detectable. (assets.press.princeton.edu)
• Keccak-256 vs SHA-3-256: Closely related; differ in padding. Ethereum uses Keccak-256, not the finalized FIPS-202 SHA-3-256. (Ethereum Stack Exchange)

---