Nodes and verification
Why BSV wallets verify with block headers and merkle proofs instead of running a node, and what that means for the screens you build.
A wallet needs to know that a payment is real. On BSV it checks that with block headers and merkle proofs, not by running a node, and that removes screens rather than adding them.
Users do not run nodes on BSV, and they do not need to. Nodes are mining infrastructure. A wallet only needs to check proofs against headers.
What a wallet actually verifies
The method is simplified payment verification, which is described in the original Bitcoin paper.
A wallet keeps block headers, a small chain of fixed-size records, one per block. To check a payment, it needs a merkle proof: the short list of hashes that connects a transaction to the merkle root in a header it already holds. If the proof reconstructs a root that sits in a header on the chain the network has built on, the transaction is in that block.
This is cheap. Headers are tens of megabytes for the whole chain's history, against terabytes for every transaction, and a proof is a few hundred bytes. A phone can do it, and so can a signing device that has been in a drawer.
What SPV does and does not establish
It establishes that a transaction was mined into a block on the chain the network has built on. It does not by itself establish that no conflicting spend was seen first, or who sent it. Those are separate questions, answered by the first-seen rule and by identity. See Transactions and Identity.
Proofs arrive with the payment
A BSV wallet does not usually go looking for a proof. The proof arrives with the payment.
A peer-to-peer payment is handed over as BEEF (BRC-62), a package containing the transaction, its ancestor transactions, and the merkle paths (BRC-74) proving the confirmed ones are in blocks. Ancestors come before the transactions that spend them, and the payment comes last, so a recipient can walk the chain of spends from a proven block forward to the payment in front of them.
From that package alone a recipient can check:
- each transaction's id matches its bytes
- each merkle path reconstructs a merkle root
- for anything unconfirmed, the parents are present, the spending rules are met, and the money going in covers the money going out
One thing is still needed from outside: the headers. BEEF proves the package is internally consistent. It cannot prove the roots it computes belong to real blocks. For that the wallet checks the roots against headers it holds or against a header service.
Recommendation
Keep headers synced quietly in the background and never make it a user-facing task. If headers are stale, say what that means for the user ("can't confirm payments from the last 3 days") rather than showing a sync percentage they can do nothing about.
Where wallets get what they need
Three services sit between a wallet and the network. None of them is a node the user runs.
| Service | What it does | What happens if it lies or fails |
|---|---|---|
| Header service | Supplies block headers | The wallet cannot confirm proofs. It should hold its own copy and prefer more than one source. |
| Broadcast service (such as ARC) | Submits transactions to miners, returns status and the merkle path once mined | Payments cannot be broadcast. The wallet should be able to use another. |
| Overlay or storage service | Tracks outputs and records for a particular application or token type | The wallet cannot show or spend those assets. |
ARC is the common broadcast service. A wallet submits a transaction, ARC validates and propagates it, and once mined it returns the merkle path, either to a callback URL the wallet registered or when the wallet asks. That path is what the wallet stores and later hands on to whoever it pays next.
Do
Let a wallet point at a different service provider, and ideally more than one at a time. A wallet welded to one company's endpoint has that company's lifespan.
Don't
Trust a single service's word that a payment is confirmed. The merkle proof is the evidence; verify it against headers rather than displaying whatever the API returned.
What Teranode is, and why it is not your problem
Teranode is the node software built to process very high transaction volumes, by splitting the work across services rather than running it in one process. It matters to miners and to businesses running their own infrastructure at scale.
It is not something a wallet or an app interacts with directly, and it is not something to explain to users. A product designer's interest in it is indirect: it is built so that capacity can keep up with demand, which is what keeps fees negligible and leaves no fee picker to design. See Transactions.
What this removes from your interface
Screens a BSV wallet does not need:
- Node settings. No host, port, or "connect to my node".
- Initial block download. Nothing to download and no progress bar to wait through.
- Confirmation counters as the primary signal. Acceptance by the recipient comes first. The mined state is a later, quieter update. See Transactions.
- "Scanning the blockchain". A restored wallet rebuilds from its records, not by scanning. See Backups.
Do
Put the services a wallet uses in an advanced settings screen, with what each one is for in one line. Users who care should be able to see and change them.
Don't
Put verification in front of ordinary users. Nobody should have to understand merkle proofs to be paid.
Related
- Transactions: first-seen, and when a payment can be relied on
- Payments: how BEEF gets to the recipient
- External signers: verifying offline
Written from: BRC-9, BRC-62, BRC-74, BRC-95, ts-stack docs, ARC documentation.
Checklist
The rules on this page, in a form you can work through.
5 rules