Verifiability: How Blockchain Transactions Are Verified

Verifiability in cryptocurrency is the ability of a participant in a blockchain network to check transactions and blocks themselves against the consensus rules, the rules that every block and transaction must meet. In Bitcoin, a participant who runs a full blockchain node, which downloads and checks every block, can verify every transaction and block, and a light client checks less.

Who Performs Blockchain Verification, and by Which Rules?

Full nodes perform blockchain verification, and each full node applies the same consensus rules on its own. The consensus rules are the rules that decide whether a transaction or block is valid for the whole network, and they set what a transaction must contain and what a block must contain.

Bitcoin is a cryptocurrency, and a node is a computer that connects to the Bitcoin network. A block is a group of transactions that the network adds to the blockchain, the chain of all blocks. A full node is a node that downloads every block, validates blocks and transactions by checking each one against the consensus rules, and passes the valid ones on to its peers, the other nodes it connects to.

Each full node builds its own chain from blocks that it has validated (a pruned full node keeps only recent block data). This is independent verification: the checking is repeated by each full node instead of being done once by a central party. This entry uses verify, validate, and check for the same act, which is comparing a transaction or block with the consensus rules.

A mining operator’s role is to add blocks. A mining operator is a person or company that adds blocks to the blockchain by running bitcoin miners, the hardware units that mine Bitcoin. The mining operator assembles or receives a block template, the list of transactions proposed for the next block, and turns it into a finished block, which the full nodes then check.

How Are Blockchain Transactions Verified, Step by Step?

Bitcoin transactions are verified in four steps, and full nodes do the checking in the second and third steps.

1. Create and sign. A wallet, the software a user sends BTC from, builds a transaction that spends earlier outputs, which are its inputs, and creates new outputs. An output is an amount of BTC that a transaction assigns to a recipient. The wallet signs the transaction with the sender’s private key, a secret that only the sender is meant to hold.
2. Broadcast and check. The wallet sends the transaction to a node, and each full node that receives it checks it. A node that finds the transaction valid may keep it in its own mempool, a waiting pool of transactions that are not in a block yet, and may pass it on to its peers, depending on its relay policy, the extra rules that only that node applies.
3. Include in a block. A mining operator includes waiting transactions in a block. A transaction is confirmed once a block includes it, and that block counts as its first confirmation. Full nodes check the block.
4. Add confirmations. Mining operators add later blocks. Each block after the one that holds the transaction adds one more confirmation, and more confirmations are designed to make it harder to replace the block that holds the transaction.

What Does a Full Node Verify in a Transaction?

Transaction verification is the set of checks that a full node makes on a transaction before it keeps the transaction or passes it on. When a full node validates a new transaction, it checks, among other things, the following.

• Unspent outputs. Each input must refer to an output that is still unspent, and this is the double-spend check, because an output can be spent only once.
• Spending condition. Each input’s data, typically a digital signature, must satisfy the spending condition of the output that the input spends. A spending condition is the rule that an output sets for who may spend it, and a digital signature is a cryptographic proof that the holder of a private key authorized the transaction. To check a signature, a full node needs only the public key, the shareable counterpart of the private key, and the signed data, and the check passes or fails.
• Amounts. The outputs must not add up to more than the inputs, and the difference is the transaction fee.
• Structure. The transaction must be well formed: it needs at least one input and one output, no input may be listed twice, each output value must be within the allowed range, and the transaction may not exceed the size limit that the consensus rules set.

What Does a Full Node Verify in a Block?

Block validation is the set of checks that a full node makes on each block it receives before it adds the block to its chain. Each block has a header, the data fields at the top of the block.

• Proof of work (PoW) . Proof of work is the rule that a block is valid only if the hash of its header is at or below the target, a limit that the network’s rules set for a valid hash. A hash is a fixed-size number that a function computes from data. A full node runs this proof-of-work check on every block.
• Header link. The header holds the hash of the previous block’s header, which chains the blocks together, and a full node cannot validate a block until it has the block’s parent, the previous block. The same link makes a change visible: a participant with copies of the blocks can recompute a header’s hash and compare it with the value stored in the next block, and a changed block no longer matches.
• Transactions. The Merkle root, a hash in the header that is calculated from the block’s transactions, must match those transactions. Every transaction in the block except the first must also pass the transaction checks.
• Coinbase claim. At the protocol level, the first transaction in a block, the coinbase transaction, has no input to check, and it may claim no more than the block subsidy, the newly created BTC in the block’s reward, plus the transaction fees in that block.
• Block weight. The block must stay within the weight limit, the cap that the consensus rules set on how much room the block’s transactions may take, measured in weight units.

Full nodes are designed to reject a block that breaks any consensus rule, even when the block’s proof of work meets the target.

Which Main Checks Does a Full Node Run, and Where Is Each Explained?

These are the main checks that a full node runs, not a complete list, and each row names the glossary entry that explains it.

Main check	Compared with	Glossary entry
Each input refers to an unspent output	The node’s record of unspent outputs	UTXO (unspent transaction output)
An input’s data satisfies the output’s spending condition	The public key and the signed transaction data	ECDSA and Schnorr signatures
Outputs do not add up to more than inputs	The total of the inputs	UTXO
The header hash is at or below the target	The target	Proof of work
The header names a previous block that the node already has	The node’s own blocks	Cryptographic hash
The Merkle root matches the block’s transactions	A hash calculated from those transactions	Cryptographic hash
The first transaction claims no more than subsidy plus fees	Subsidy plus fees	Block reward

What Does a Light Client Check, and What Does It Trust?

A light client checks that a transaction is included in a block, and it relies on full nodes and on the chain with the most work for everything else. A participant who runs a full node can check every block and every transaction, starting from the first block, the genesis block, using the blockchain, the shared public ledger of blocks.

A light client is software that uses the Bitcoin network without downloading and checking every block and transaction. It keeps only block headers and asks a full node for a Merkle branch, also called a Merkle proof, which is a short chain of hashes that links a transaction to the block that holds it. A light client is also called an SPV client, for simplified payment verification, and there “verification” means checking inclusion in a block, not every rule.

A light client cannot check that a transaction follows every rule. It relies on full nodes to give it Merkle tree branches, and it follows the chain that took the most work to produce. Relying on that chain works as long as participants who follow the rules control most of the network’s hashrate, the combined number of hashes per second that bitcoin miners compute. An attacker who controls most of the hashrate could fool a light client with fabricated transactions.

Why Is Checking a Block Cheaper Than Producing One?

Checking a block is cheaper than producing one because the block’s work takes a very large number of hashes to find and only one hash computation to check. A mining operator produces a block by changing the nonce, a number stored in the header, and hashing the header again and again until the hash is at or below the target, the limit that the network’s rules set for a valid hash. That repeated hashing is the work that proof of work requires of each block.

A full node checks the same work by computing the header’s hash and comparing it with the target. This gap between producing and checking is what lets every full node check the work for itself instead of trusting the mining operator.

As of October 2026, finding one block takes more than 500 sextillion hashes on average (a sextillion is 10 to the power of 21), and checking its work takes one hash computation. The figure moves with network difficulty, which the network adjusts every 2,016 blocks. It illustrates scale, not a cost, earnings or attack estimate.

What Does Verifiability Not Mean?

Verifiability does not mean that a transaction is legal, accurate, or a good idea, because a full node checks only that the transaction follows the consensus rules. Verifiability does not protect a sender who made a mistake or was misled. A payment to a valid but wrong address passes the checks, and so does a payment to a person who misled the sender, because the checks look at the rules and not at why the sender paid.

Verifiability does not mean that a participant knows who sent a transaction. A valid signature shows that someone holding the private key authorized the spend, and it does not show who that person is, because a person who copied the key could produce an equally valid signature.

Verifiability does not mean that a transaction can be reversed, and it does not mean that it cannot be. Passing the checks shows only that a transaction is valid under the rules, and the irreversibility of transactions entry covers what confirmations change.

Verifiability does not mean that a network cannot be attacked. A party with most of the hashrate could replace recent blocks with a different version, and no number of confirmations removes that possibility. The 51% attack and double spending entry covers the mechanism.

As of October 2026, Bitcoin’s consensus mechanism, a set of rules that lets many computers agree on one shared record without a central party, is proof of work, and this entry covers Bitcoin only, not the other consensus mechanisms that other networks use.