Light Clients and SPV
Verifying transactions without the full blockchain (non-consensus)
Simplified Payment Verification (SPV) lets a party confirm that a transaction is included in a block without storing the full blockchain — it needs only the block headers and a Merkle proof for the transaction of interest. A client that operates this way, rather than producing blocks, is a light client. The white paper describes simplified payment verification:
"It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in." — Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, §8
A recipient of a payment is given the raw transaction and the Merkle proof(s) for the outputs it spends, and can verify it independently. It can accept the transaction before it is mined: under the first-seen rule a node rejects any later transaction that double-spends the same output, so a transaction that has propagated is unlikely to be displaced ("zero-confirmation" acceptance).
Full verification involves three checks.
Proof of publication
Proof of publication shows a transaction is included in a block. The verifier needs block headers (from a block-header client), the raw transaction, and a Merkle proof (the sibling hashes on the path from the transaction to the root). It recomputes the Merkle root from the transaction id and the proof (see Merkle root construction) and compares it to hashMerkleRoot in the block header; a match proves inclusion. Because this needs only headers plus a short proof — independent of the number of transactions in the block — it scales to arbitrarily large blocks.
Data sizes: headers ≈ 4.2 MB/year (80 bytes × ~52,416 blocks); a simple P2PKH transaction ≈ 400 bytes; a Merkle proof ≈ 1 KB even for a block of billions of transactions (proof size grows with the log of the transaction count).
Signature validity
The second check verifies the spend is authorised — that the input carries a valid signature for the output it spends. The signature is verified over the transaction signature-hash, whose digest incorporates fields of both the spending transaction and the spent output, including that output's value and locking script, per the sighash flags (see Signature Hashing). Because the digest covers the spent output's value and script, a valid signature attests to the integrity of the output being spent as well as to authorisation. The verification is OP_CHECKSIG / OP_CHECKMULTISIG (Opcodes). Every check can be done locally except the final double-spend check against the live UTXO set, which requires a node.
Proof of integrity
A signature is only meaningful if the locking script of the spent output actually requires a signature from a specific key. Consider a standard pay-to-public-key-hash output:
This requires a public key that hashes to <Public Key Hash> and a valid signature from it — the spend is bound to a specific key. By contrast, a locking script that names no key, such as bare OP_CHECKSIG (satisfied by any signature/public-key pair) or OP_DROP OP_DROP OP_TRUE (satisfied by any two items), proves nothing about who was entitled to the output. A locking script provides integrity only if it (1) specifies the public key or its hash and (2) explicitly requires a signature over the transaction.
Verifying all three — publication, a valid signature, and a locking script that genuinely constrains the spend — establishes that a transaction is present and correctly authorised.
Last updated