What is SPV?What is SPV?

Simplified Payment Verification (SPV) is described in the whitepaper (section 8) as only downloading the block headers and then checking to see if transactions have been included in a block.

Someone using SPV can’t verify the transaction themselves, but they can determine whether the nodes they are connected to think it is a legitimate transaction. In this sense, SPV nodes outsource verification to their connections.

The Schildbach Bitcoin Wallet, one of the earliest Android wallets, is a great example of an SPV client. It does not query a public electrum server for information about blocks, opting instead to use simplified payment verification to determine if transactions have been included in blocks that are part of the chain with the most weight.

SPV is cool because it doesn’t lead to the same kind of privacy leakage that querying a public electrum server might and it doesn’t carry the same storage and compute requirements of a full node – so it’s easy to run on small or old devices.

The downside is that you are vulnerable to sybil attacks, and if too many people run SPV clients, the network starts to look more like hub and spoke where most people are trusting a central server.

AssumeUTXOAssumeUTXO

AssumeUTXO is a proposal where developers would include a snapshot of the UTXO set in node software and users could choose to trust this snapshot rather than validating every transaction and building the set of unspent UTXOs from genesis.

This would allow a node to skip (or perform later in the background) a large portion of the initial block download, meaning that your node could get synced much more quickly. However, it would also mean that you are trusting the nodes to which you are connected in a manner similar to SPV, rather than validating things for yourself.

As a side note, default Bitcoin Core nodes use something called assumevalid which skips validation of scripts in blocks created more than a month or two before the release of the version of Bitcoin Core being run. This is also a "trust me bro" position.

Both SPV and AssumeUTXO seem to me to be less trusting than just relying entirely on someone else’s node.

It’s not "Trust me, bro" it’s "Trust me, bro"It’s not "Trust me, bro" it’s "Trust me, bro"

Perhaps you recall our friend secsovereign on X. He’s got an LLM and he’s not afraid to use it to fix Bitcoin (#1392522). Part of his grand Bitcoin Commons plan is to have people rely on what he calls UTXO commitments...which sounds a lot like AssumeUTXO.

Secsovereign recently attempted to describe the trust model of his Bitcoin Commons implementation:

I’m using peer consensus on UTXO set state at block heights. New nodes:

1. Verify full PoW header chain
2. Get peer consensus on UTXO set hash at recent height (multiple peers agree)
3. Download UTXO set from peers
4. Verify downloaded set matches peer consensus hash
5. Fully validate all new blocks going forward Not SPV security. It’s peer consensus verification of state without replaying history, then full validation from there. Archival nodes still needed for fraud proofs and historical verification.

The point is to eliminate ~98% of IBD cost (processing all historical spam) while maintaining verification security. Most nodes don’t need to process 2021 monkey jpegs to verify current state.

Notice that Secsovereign says his implementation is "Not SPV security."

"Who needs a chain? Let’s just have consensus!""Who needs a chain? Let’s just have consensus!"

Eric Voskuil took issue with Secsovereign’s description of his security model as "not SPV":

The only way the utxo set can be validated is by validating the full chain. This is the same with SPV block hash commitments. Merkle trees may or may not represent valid txs/blocks. And hash commitments may or may not represent a valid utxo set (and thereby valid txs/blocks).

In response, Secsovereign had his LLM generate this handy table to explain the differences between his model and SPV:

If you can’t tell, the table is total bullshit.

Secsovereign adds to the bullshit by saying:

The fundamental difference from SPV is that SPV never validates transactions. Commons fully validates every transaction from commitment point forward with the same cryptographic guarantees as a fully synced node. The trust model applies only to historical state, not ongoing validation.

The part I put in bold is just plain wrong (so is the last part).

Voskuil explains that if your starting point is a UTXO commitment,

Future blocks cannot be proven valid except under the assumption that previous blocks were valid. The whole thing rests on that assumption, just as with an SPV node. The trust is based on the assumption that everyone else is validating and it’s therefore good enough.

There is no free validationThere is no free validation

Let’s go back to Secsovereign’s description of the Bitcoin Commons trust model. Near the end he says:

The point is to eliminate ~98% of IBD cost (processing all historical spam) while maintaining verification security.

This is his whole mistake in one sentence: you cannot maintain the same security guarantees if you trust someone to tell you the chain state at any point.

Secsovereign seems to think that you can start from a position of trust and still get "the same cryptographic guarantees as a fully synced node" as long as you validate going forward. This is not true. If you accept someone else’s story of where all the bitcoins are (the UTXO set, the state, whatever you want to call it), you might as well trust them about all transactions.

SPV nodes try to place bounds on this by checking to see if the transaction is included in a block, but this really is just trusting that the peers you are connected to aren’t lying about the chain. It’s the same assumption as AssumeUTXO: I assume I’m connected to honest peers, but the only way I can tell I am being lied to, is if I am actually connected to at least one honest peer.

Secsovereign’s UTXO commitment scheme is no different. He ends up trying to argue that if you do a good enough job with Sybil resistace, you can move the security model from trust to proof:

When using peer consensus for UTXO state, Sybil resistance IS the security model. The threat is fake peers providing invalid UTXO set. ASN diversity, geographic distribution, and configurable peer thresholds address this. I’m identifying the actual attack vector, you’re reframing as proof vs trust.

It’s kind of shocking that Secsovereign, who claims to be writing a new implementation of Bitcoin, doesn’t get this: the reason Satoshi bothered with all the cryptography and proof of work and difficulty adjustments is so that you don’t have to trust your peers.

What Secsovereign is proposing sounds like proof of agreement: as long as all of my peers say it’s true, it must be true – which is not the security model of a fully synced node. When validating the chain from genesis, you have the chance to prove your peers are lying, even if none of them are honest.

---

This conversation is a case of Secsovereign overly relying on an LLM to produce slop answers rather than learning how Bitcoin works. He doesn’t think he needs to understand the difference between a checkpoint and a commitment, and he doesn’t get the difference between assuming you have at least one honest peer, and being able to tell that you don’t.

It is often the case that trying to figure something out for yourself helps you understand the thing. Using LLMs can speed the process up, but it can also take the pain away and trick you into thinking you understand something when the reality is that you do not.