Hash Function

Overview

Why Hash Function matters

Networks need compact fingerprints for potentially large pieces of data. A payment service may wish to detect whether a payload changed, and blockchain nodes must compare transaction or block content efficiently. Cryptographic hashes help because even a tiny input change will generally produce an unrelated-looking digest, while the output has a predictable length.

How it works

Consider SHA-256, which processes arbitrary-length data to produce a 256-bit digest. Hash security is described using different properties. Preimage resistance means that, given a digest, finding a matching input should be computationally infeasible. Second-preimage resistance means it should be difficult to find a different message matching one specific original. Collision resistance means finding any two different inputs with the same digest should also be hard; generic collision searches scale approximately with the square root of the output space. A block header may include a hash commitment to its previous block, and a Merkle tree can combine transaction hashes so a small proof shows inclusion under a known root. The digest does not state who created the data or whether it is accurate.

Why a 256-bit hash is not a 256-bit password

A digest of random-looking length does not tell you how many guesses an attacker needs if the input is predictable. For example, hashing the word "password123" with SHA-256 produces a long digest, but an attacker who guesses common passwords can compute the same hash quickly. That is why passwords use deliberately slow, salted password-hashing mechanisms. For blockchains, hashes are often used with high-entropy block data, transaction encodings and cryptographic commitments, so their security requirements are different. Also notice that a transaction ID is a hash of the network's specified transaction serialization, which may have network-specific details. Two visually similar transfers need not share an ID, and a hash obtained from the wrong network does not prove payment. Cryptographic properties must always be interpreted in their specific context.

A real-world payment example

A merchant keeps a reference to a transaction hash in an accounting record. Later a support agent uses that hash in the correct network explorer to examine the public transfer. If the customer shares an unrelated hash from another chain, the identifier alone does not prove the order was paid. The destination, asset, amount and confirmation state still need checking.

Limits and common misunderstandings

Ordinary checksums detect accidental errors; cryptographic hashes are designed against malicious manipulation as well. Hashing a password without a proper password-hashing scheme is not sufficient credential protection. A hash is not a unique ID in a strict mathematical sense: different inputs can theoretically share an output.

How it differs from related concepts

A hash function produces a digest. A digital signature authenticates authorization. Encryption protects confidentiality. Their purposes overlap in systems but should not be confused.

Explore further

Official background: technical documentation.

Related glossary terms: Transaction Hash, Blockchain, Block.