How Nodes Validate Transactions

Before a Bitcoin transaction can be included in a block, it must sit in a temporary queue called the mempool (memory pool). However, a node will not let just any transaction enter its mempool.

When your node receives a new transaction from a peer, it executes a battery of dozens of rigorous validation checks to ensure it conforms exactly to the consensus rules of the network. If a transaction fails even a single test, it is instantly rejected and discarded.

Here is the exact step-by-step verification process a node executes on every transaction.

---

🔎 The Node's Validation Checklist

             New Transaction
                   │
                   ▼
       [ 1. Syntax & Size Checks ] ─────► Fail ──► Reject
                   │ Pass
                   ▼
       [ 2. UTXO Database Check ]  ─────► Fail ──► Reject
                   │ Pass
                   ▼
       [ 3. Locktime Validation ]  ─────► Fail ──► Reject
                   │ Pass
                   ▼
       [ 4. Script & Signature ]   ─────► Fail ──► Reject
                   │ Pass
                   ▼
        Added to Local Mempool

1. Syntactic and Structure Checks

Before doing any complex cryptography, the node performs cheap, fast structural checks: * Non-empty: The lists of inputs and outputs must not be empty. * Size Constraints: The transaction's raw size in bytes must be below standard limits (typically a maximum of 100,000 bytes) to prevent miners or attackers from flooding nodes with massive, resource-hogging transactions. * Mathematical Bounds: The total sum of the output values must not exceed the maximum allowed Bitcoin supply of 21,000,000 coins, and none of the outputs can have a negative value (which could be used to inflate the supply).

2. UTXO and Double-Spend Checks

The node checks the transaction's inputs against its local UTXO set (the database of unspent transaction outputs): * Existence: Each input must reference a valid, existing transaction output in the UTXO database. If the output does not exist, the transaction is fake. * Double-Spend Prevention: The node verifies that none of the inputs are already marked as spent by another transaction sitting in the node's mempool or already confirmed in the blockchain. * In-Mempool Inputs: If an input spends a UTXO that was created by a transaction still waiting in the mempool (not yet in a block), the node accepts it but links them as a dependent chain.

3. Locktime and Sequence Validation

Bitcoin supports time-delayed transactions. The node checks: * nLockTime: If the transaction header specifies an nLockTime (a future block height or Unix timestamp), the node verifies whether the current network time or block height has passed this limit. If it has not, the transaction cannot enter the mempool. * Relative Timelocks (nSequence): If the input uses relative timelocks, the node verifies that the required number of blocks or seconds have elapsed since the parent transaction was confirmed.

4. Cryptographic Validation (The Script Interpreter)

This is the most CPU-intensive step. The node runs Bitcoin's virtual machine script interpreter to verify ownership: * Script Pairing: For each input, the node pairs the unlocking script (the ScriptSig containing the digital signature) with the locking script (the ScriptPubKey from the parent UTXO). * Execution: The combined script is executed on a stack. If the script runs to completion and leaves a value of TRUE on the stack, the ownership is verified. * Signature Verification: The node verifies that the mathematical elliptic curve signatures (ECDSA or Schnorr) match the public keys provided, proving that the person broadcasting the transaction is the actual owner of the private keys.

5. Transaction Fee Verification

A transaction's fee is not written as a field in the transaction. Instead, it is calculated implicitly: $$\text{Fee} = \sum \text{Input Values} - \sum \text{Output Values}$$

The node checks: * Profitability: The sum of inputs must be greater than or equal to the sum of outputs. If outputs are larger, the transaction is trying to inflate the coin supply and is instantly rejected. * Min Relay Fee: The calculated fee, divided by the transaction's size in bytes, must meet or exceed the node's Minimum Relay Fee Policy (usually set to 0.00001 BTC or 1 sat/vByte). If the fee is too low, the node will refuse to store or propagate it to save bandwidth.

---

🛡️ Trustless Security

Because every node running on the network performs these exact same checks independently, cheating is impossible.

If a malicious actor tries to broadcast a fake transaction with a forged signature, the first node that hears it will run these tests, fail the transaction, and refuse to pass it along. The attack is stopped dead in its tracks before ever reaching a miner.