> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/implementation-notes/light-clients-and-spv.md). # Light Clients and SPV {% hint style="info" %} Light clients and SPV are how applications *use* the chain; they are not part of the consensus rules. This page describes the verification the protocol makes possible. Wallets, key management, and other application infrastructure are out of scope for this reference. {% endhint %} **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](/bitcoin-protocol-documentation/specification/consensus-rules.md#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).

SPV verification flow

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](/bitcoin-protocol-documentation/specification/blocks.md#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](/bitcoin-protocol-documentation/specification/signature-hashing.md)). 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](/bitcoin-protocol-documentation/specification/opcodes.md#cryptography)). Every check can be done locally except the final double-spend check against the live UTXO set, which requires a node.

The signed message draws fields from both transactions

## 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: ``` Locking: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG Unlocking: ``` This requires a public key that hashes to `` 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/implementation-notes/light-clients-and-spv.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.