Hash functions in practice

Why hashes matter beyond the block header

A cryptographic hash function converts a piece of digital information into a short, fixed-size result called a hash value or digest. The input may be a sentence, a document, a transaction, or a collection of records. A secure hash is designed so that even a small change in the input produces an output that appears unrelated to the original. This property is valuable in a blockchain because participants need to compare information without repeatedly inspecting every byte of a large data set. It is also valuable off-chain, when an auditor wants to check whether evidence has changed between collection and review. A hash is a fingerprint-like comparison tool, not an identity card and not a guarantee that the underlying information is true.

SHA-256, a member of the SHA-2 family described in National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 180-4, Secure Hash Standard, produces 256 bits, commonly displayed as 64 hexadecimal characters. Hexadecimal uses digits 0 through 9 and letters a through f to represent binary values compactly. Regardless of whether the original input contains three characters or three million, a SHA-256 digest has the same length. This fixed length makes digests convenient identifiers and integrity checks; it does not mean that a digest contains enough information to reconstruct the original input.

Three properties worth distinguishing

Preimage resistance and one-way computation

Preimage resistance means that, given a hash value, finding an input that produces it should be computationally infeasible for a secure hash used properly. Hashing is therefore not encryption: encryption is designed to allow authorized recovery of plaintext using a key, while a hash normally offers no decryption operation. It is also not a method for protecting a guessable secret by itself. For example, hashing a short password does not make the password hard to guess if an attacker can hash common candidates. Password storage requires separate techniques such as salts and purpose-built, deliberately expensive password hashing. Those operational details are outside this course, but the distinction prevents a frequent misconception.

Second-preimage and collision resistance

Second-preimage resistance concerns finding a different input with the same digest as a specified input. Collision resistance concerns finding any two distinct inputs that produce the same digest. Because there are infinitely many possible inputs but only finitely many outputs, collisions must exist in principle. A well-designed cryptographic hash makes useful collisions extremely difficult to discover. A 256-bit output does not imply 256-bit collision resistance: the birthday effect gives generic collision searches a lower security bound than preimage searches. Learners should recognize the three terms without treating them as interchangeable, or assuming every algorithm has remained equally secure over time.

The bytes being hashed are decisive

Two people can hash what appears to be the same document and obtain different digests if they do not use identical bytes. One file may have a different line ending; a copied paragraph may contain another Unicode representation of the same visible character; a spreadsheet may carry hidden metadata. Hash functions do not understand that two files look alike. They process specific byte sequences. Before comparing results, identify the file format, character encoding, precise input scope, and hashing algorithm. Recording these details is part of a reproducible audit trail.

Consider a PDF contract. Hashing the exact PDF file can help detect later changes to that file, including changes not apparent on the page. It does not by itself show whether the contract was lawfully executed, whether a signatory understood the terms, or whether the file was accurate when first received. An organization may record a digest together with the source, collection time, responsible officer, and handling history. The digest supports a claim about file continuity; those surrounding records support provenance. Neither should be confused with an independent certification of the content.

Common uses in digital-asset systems

Transaction identifiers are frequently based on hashes of a protocol-defined transaction representation. An identifier allows nodes and analysts to refer to a specific data object; its precise computation depends on the network. In Bitcoin, the conventional transaction ID (txid) is calculated from the non-witness transaction serialization using a double application of SHA-256, while a witness transaction identifier (wtxid) commits to witness-inclusive serialization. This distinction matters when comparing software outputs. Other networks may use a different algorithm or treat a signature as the transaction's lookup identifier. Never assume that every string labeled “transaction hash” was calculated in the same way.

Hashes also enable compact commitments to collections of records. A Merkle tree combines hashes in layers until one digest, called a Merkle root, represents the included leaves under a specified construction. A proof can then demonstrate that a particular item was part of the committed collection without transmitting every other item. This demonstrates inclusion relative to a known root; it does not establish the real-world meaning of the item. The previous module introduced the role of hashes in block linking. Here the transferable lesson is that hash-based commitments are precise, limited claims about data relationships.

Hash algorithms are not interchangeable

Names that sound similar may conceal technical differences. NIST FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, defines SHA3-256, among other functions. Ethereum's widely used Keccak-256 construction is related to the Keccak family but should not be casually treated as byte-for-byte identical to standardized SHA3-256; their padding conventions differ. Likewise, SHA-256 and double-SHA-256 are distinct computations. An analyst verifying a value must use the algorithm and exact encoding specified by the relevant protocol rather than choose a familiar hash function from a software menu.

A practical comparison procedure

1. Identify exactly what object is being compared: a full file, its contents, a serialized transaction, or a displayed address.
2. Record the algorithm and the representation used, including encoding, network, and any included or excluded fields.
3. Compute or obtain the digest independently and compare the complete value rather than an abbreviated prefix.
4. If the result differs, investigate byte-level or representation differences before drawing conclusions about fraud or alteration.

Software sometimes shows only the first and last few characters of a long digest. Such abbreviations can help a human locate a record but are inadequate as proof of an exact match. A checksum used to catch typing errors may be much shorter and is not the same thing as a cryptographic content digest. For a formal comparison, preserve the full digest and contextual details in a way that can be repeated by another reviewer. The strongest statements are narrow: “these exact bytes matched under this specified algorithm,” rather than “this document is authentic in every respect.”

Exam focus: Explain fixed output size, the one-way property, collision versus preimage resistance, and why hashing detects byte changes but cannot prove the accuracy or legal authenticity of a record. Be able to distinguish SHA-256, SHA3-256, and Keccak-256 by their names and specifications, and recognize why exact input serialization matters.