20 standards
The proof an SPV check runs on: a path of hashes from one transaction up to the root recorded in a block header. Several standards here define formats for that path, each one more compact than the last.
Also searched as merkle path, BUMP, STUMP, TSC proof, merkle root, inclusion proof.
The sequence of hashes that connects one transaction to the merkle root in a block header. Following it proves the transaction was included in that block without needing the rest of the block.
Open in the glossary20 standards, spread across 5 of the 12 topics.
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.
Filed under Transactions
Merkle proofs is the main subject of these 8.
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.
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.
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.
Storing a proof in a database means keeping it small and quick to read back. This defines a compact binary shape for a single transaction's proof, aimed at storage rather than transmission.
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.
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.
Large files are usually treated as one indivisible blob: you can't name it until the whole thing has finished uploading, a single failed byte range means retrying the entire download, and there's no way to prove a partial chunk actually belongs to the file it claims to be part of. This makes streaming uploads, resumable downloads, and safe partial reads of big files awkward or impossible with simple whole-file hashing.
These are about something else, and deal with merkle proofs 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.
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.
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.
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.
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.
The standard way for a device to say which network broadcasts it wants was designed for a handful of groups, not for blockchain traffic at scale. This examines where it falls short and what would have to change.
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.
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.
When an AI system makes a decision that matters, there is usually no way to check afterwards what it actually did. This records each decision so it can be independently verified later, without exposing the model itself.
An index cannot easily prove it has seen everything relevant in a block rather than most of it. This gives a per-block summary that makes completeness checkable rather than assumed.
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.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic