32 standards
Simplified Payment Verification. A recipient checks that a transaction is in a block by verifying a proof against block headers, instead of running a full node. It is what makes a wallet on a phone possible.
Also searched as Simplified Payment Verification, verification, light client.
Checking that a transaction is in a block by verifying a merkle proof against block headers, instead of downloading and validating the whole chain. It is what lets a wallet on a phone accept a payment.
Open in the glossary32 standards, spread across 7 of the 12 topics.
Earlier descriptions of how a light client checks a payment were spread across documents and leaned on each other. This states the process on its own terms so it can be read and implemented without following a trail of references.
Filed under Transactions
SPV is the main subject of these 7.
Confirming a payment traditionally means running a full copy of the blockchain, which is far too heavy for a phone or a web page. This describes how a recipient can satisfy themselves a payment is genuine using only block headers and a short proof.
A miner interface gained wide adoption and an equal amount of criticism, with some of its uses pulling against how the network is meant to work. This sets out which of those uses are legitimate and which are not.
Earlier descriptions of how a light client checks a payment were spread across documents and leaned on each other. This states the process on its own terms so it can be read and implemented without following a trail of references.
A wallet can hand out a fresh receive address to anyone, but if that sender is a custodial exchange, swap service, or anyone who just sends money without telling the wallet, there is no way for the wallet to notice the payment arrived. Watching every possible address the wallet could ever generate is slow, leaks privacy, and can still miss late payments. This lets a wallet reliably notice payments to addresses it gave out, without the sender's cooperation and without scanning forever.
When someone sends you a token on Bitcoin, you cannot just trust the number they tell you: you need to check it came from a real issuance and was never double-counted through splits or merges, without running a full blockchain indexer. Existing proof formats either strip out the very transaction history token math depends on, or only work for simple single-path assets, leaving no safe way to check a token tip you just received while offline.
Wallets that show balances for chains other than BSV, like Litecoin or Dogecoin, usually have to trust a custodian holding wrapped tokens or an indexer reporting balances and confirmations, putting a third party between the user and their money. This makes it possible for a wallet to hold and spend coins on another chain directly, verifying everything itself from raw transaction bytes and its own copy of that chain's block headers.
Two different wallets checking the same unconfirmed payment describe what they verified in totally different ways, so there is no way to compare "three hops back to a confirmed block" against "a valid BEEF" or to let an app set one acceptance rule that works regardless of which wallet it is talking to. This leaves users and apps guessing what was actually checked before goods change hands, with no shared way to say it.
These are about something else, and deal with spv on the way.
Sending someone a transaction is not enough for them to trust it: they also need the earlier transactions and the proofs showing the money is real. This defines a single package carrying all of it, so software from two different vendors can exchange a payment the recipient can actually check.
Several documents refer to the same existing merkle proof format, and calling it different things invites confusion. This gives that format a number in this series so other proposals can point at it without ambiguity.
Merkle proofs identify the block they belong to by its hash, which means anyone checking one has to keep every block hash to look it up. This argues for using the block's height instead, roughly halving what a lightweight client needs to store.
Sending an ordinary Bitcoin payment leaves the recipient unsure whether it is real without checking the whole chain. This defines a straightforward payment between two parties that the recipient can verify independently, and that any compliant wallet can take part in.
A transaction on its own does not carry enough to check that its signatures are valid: the amounts and locks being spent live in earlier transactions. This adds those missing pieces, so a service can validate what it is given without looking anything up.
Referring to one particular coin is easy; referring to it so another program can act on it is not, because its amount and its lock live elsewhere. This defines the smallest complete way to name an output together with what is needed to use it.
Building tokens on Bitcoin tempts people to copy account-based designs from other chains, which fits badly. This argues that an unspent output is already the natural unit of ownership and should be treated as the token itself.
A lightweight client asking a service for proof that a transaction is in a block needs that proof in a form it can read over an ordinary web request. This gives it a plain readable shape rather than raw bytes.
Some ways of tracking blockchain state require every participant to see every transaction, which stops working as volume grows. This argues that indexes watching only the slice they care about are both safer and able to scale.
Sending proofs for several transactions separately repeats the same hashes over and over. This defines a compact form that carries proofs for many transactions at once with the shared parts included only once.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
The readable-name payment scheme was built before there was a good way to send verifiable transactions. This updates it to carry the newer self-verifying bundle instead of bare transaction bytes.
Different proof formats each solved part of the problem, leaving processors and clients converting between them. This defines one format that is cheap for a transaction processor to produce and convenient for a client to check.
Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.
A bundle carrying several transactions leaves the recipient guessing which one is the subject and which are supporting evidence. This constrains the bundle to a single subject transaction so there is nothing to guess.
Two parties who have already exchanged proofs for a transaction resend all of it every time it comes up again. This lets a bundle name a transaction the other side already has instead of repeating it.
A minimal token protocol leaves amounts as plain numbers, which anyone in the chain could quietly alter. This adds a cryptographic commitment so tampering is detectable, without abandoning the minimal design.
Checking whether a token is genuine usually means trusting an indexing service to have followed its history. This makes validity provable from block headers and proofs alone, so no service has to be trusted.
A proof spanning a whole block is larger than needed when the transactions of interest sit close together. This encodes the path within a subtree instead, which is smaller for that common case.
Proving an item is the genuine one, and not a copy of it, means tracing it back to where it began. This packages that trail so it can be checked without asking any service for help.
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
Paying someone with a digital token normally means checking in with an online service at the exact moment of payment, which fails in a shop with bad signal, on a train, or at a market stall. Cash does not have this problem. This describes a way for a payment to be handed over and trusted on the spot, with the online check happening later instead of during the handoff.
Apps that show Bitcoin-derived data (like a music catalogue or a task list) often pull information from more than one source: an overlay network, a wallet's own storage, or a direct message from another peer. Without a shared discipline, an app ends up treating whichever source answered first as the single truth, so later corrections, competing hosts, or spends get silently lost or wrongly overwrite each other. This leaves developers unsure how to combine "someone claims this output exists" with "this output is actually verified on-chain" without conflating the two.
Proving something existed and was signed at a certain time normally means publishing the thing itself. This puts only a hash on the chain and issues a certificate anyone can check, so the content stays private.
Proving that a token transfer is legitimate normally means checking its entire history back to the moment the token was created, and that history gets longer every time the token changes hands. For a token that has traded thousands of times, a wallet would have to download and verify thousands of past transactions just to accept one payment. This makes long-lived, actively traded tokens slow and expensive to receive, no matter how simple the actual transfer is.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic