Transaction Verification by Nodes

11 min readarticleIncludes quiz · 5 questions

Every Bitcoin node independently verifies every transaction and block. This trustless verification is what makes Bitcoin decentralized—you don't trust miners or other users, you verify the math yourself. Understanding what nodes check helps you appreciate Bitcoin's security.

What Do Nodes Verify?

  • •Transaction syntax: Properly formatted data
  • •Signatures: Cryptographic proofs of ownership
  • •Inputs exist: Referenced UTXOs actually exist
  • •Inputs unspent: UTXOs haven't been spent already
  • •Value balance: Inputs ≥ outputs (no money creation)
  • •Script execution: Locking/unlocking scripts run correctly
  • •Consensus rules: All Bitcoin protocol rules are followed
Node Verification
Node Verification

Key Definitions:

  • •Full node: Software that downloads and verifies entire blockchain from genesis.
  • •Validation: Checking that all rules are followed.
  • •Consensus rules: The mathematical rules that define valid transactions and blocks.
  • •Script verification: Executing Bitcoin Script to check spend conditions are met.
  • •UTXO set: The database of all unspent outputs (what nodes use to verify inputs).
  • •Merkle proof: Cryptographic proof that a transaction is in a block.

Transaction Verification Steps:

1. Syntax check

  • •Is it properly formatted Bitcoin transaction data?
  • •Are all required fields present?
  • •Is size within limits?

2. Input verification

  • •Do referenced UTXOs exist?
  • •Have they already been spent (double-spend check)?
  • •Does each input signature cover the transaction?

3. Output verification

  • •Are output values ≥ dust limit?
  • •Do outputs follow script rules?
  • •Are output amounts reasonable?

4. Signature verification

  • •For each input, verify signature using public key
  • •Check signature covers correct data (transaction hash)
  • •Ensure signature type is allowed (SIGHASH flags)

5. Script execution

  • •Run scriptSig (unlocking script) + scriptPubKey (locking script)
  • •Result must be TRUE for each input
  • •Check for opcodes that are disabled

6. Value check

  • •Sum(inputs) ≥ Sum(outputs)
  • •Fee = Sum(inputs) - Sum(outputs) > 0
  • •Outputs don't exceed input values

7. Final checks

  • •Transaction not already in blockchain
  • •Check locktimes (if present)
  • •Verify sequence numbers (for RBF/timelocks)

Example Verification:

Alice's transaction:

  • •Input: 0.5 BTC UTXO from txid abc123..., output #0
  • •Output 1: 0.3 BTC to Bob
  • •Output 2: 0.1999 BTC to Alice (change)
  • •Fee: 0.0001 BTC

Node checks: 1. ✓ Syntax is valid 2. ✓ UTXO abc123...#0 exists in UTXO set 3. ✓ UTXO hasn't been spent yet 4. ✓ Alice's signature is valid (matches public key) 5. ✓ Public key hashes to address that owns the UTXO 6. ✓ 0.5 ≥ 0.3 + 0.1999 (fee = 0.0001) 7. ✓ Transaction is unique (not already in blockchain)

Result: Valid! Add to mempool and relay to peers.

Signature Verification
Signature Verification

Script Verification (Technical):

Bitcoin Script:

  • •Stack-based language (like RPN calculators)
  • •Not Turing-complete (no loops, finite execution)
  • •Deterministic (same inputs always give same output)

P2PKH unlocking (most common): ``` scriptSig: <signature> <public key> scriptPubKey: OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG ```

Execution: 1. Push signature and public key to stack 2. OP_DUP duplicates public key 3. OP_HASH160 hashes it 4. Compare hash to address (OP_EQUALVERIFY) 5. OP_CHECKSIG verifies signature

Result: If stack top is TRUE, script passes.

Double-Spend Prevention:

How nodes prevent double-spending:

1. UTXO set tracking: Nodes maintain a database of all unspent outputs. 2. First-seen rule: First valid transaction spending a UTXO is accepted. 3. Conflicting transaction: If a second transaction tries to spend the same UTXO, it's rejected. 4. Mempool check: Before relaying, check if any input is already spent in mempool. 5. Blockchain check: Check if UTXO has been spent in a confirmed block.

Example:

  • •Alice broadcasts Tx1 spending UTXO A to Bob
  • •Tx1 propagates and enters mempools
  • •Alice tries to broadcast Tx2 spending UTXO A to Carol (double-spend attempt)
  • •Nodes see UTXO A is already spent in Tx1
  • •Nodes reject Tx2
  • •Result: Only Tx1 can confirm

What Nodes DON'T Verify:

  • •Identity: Nodes don't know or care who you are
  • •Purpose: Don't check why you're sending Bitcoin
  • •Legality: Don't enforce local laws (that's beyond protocol)
  • •Fairness: Don't judge if fees are "too high" (market decides)
  • •Transaction origin: Don't trace where Bitcoin came from before this UTXO

Nodes only verify math and consensus rules.

Verification Performance:

How fast can nodes verify?

  • •Simple transaction: <1 millisecond
  • •Block of transactions: ~1-10 seconds
  • •Entire blockchain sync (from genesis): Hours to days

Factors:

  • •CPU speed
  • •Disk I/O (reading blockchain data)
  • •Number of inputs/outputs
  • •Script complexity (multisig slower than simple P2PKH)

Optimization:

Test Your Knowledge

This lesson includes a 5-question quiz (passing score: 80%).

Quiz functionality available in the mobile app.