Simplified Payment Verification (SPV)

Statt einer dritten Partei zu vertrauen, beweist ein SPV-Client die Aufnahme kryptografisch: Er lädt nur die Kette der 80-Byte-Blockheader herunter, für die gesamte Historie von Bitcoin sind das etwa 50 bis 60 Megabyte, und fragt einen verbundenen Peer nach einem Merkle-Zweig, dem kurzen Pfad von Hashes, der eine bestimmte Transaktion mit dem in einem Header gespeicherten Merkle-Root verknüpft. Stimmen die Hashes bei der Neuberechnung überein, gilt als bewiesen, dass die Transaktion in diesem Block enthalten ist, ohne dass der Client den übrigen Inhalt des Blocks je zu sehen bekommt.

Dieses Design tauscht etwas Vertrauen gegen eine deutliche Reduzierung der Ressourcen. Ein Full Node validiert jede Protokollregel gegen die vollständige Blockchain; ein SPV-Client geht dagegen davon aus, dass die längste gültige Header-Kette einen ehrlichen Konsens widerspiegelt, und verlässt sich auf Proof of Work statt auf eine unabhängige Regelprüfung. Frühe mobile Wallets nutzten BIP-37-Bloomfilter, damit Peers relevante Transaktionen zurückliefern konnten, ohne eine exakte Adressliste preiszugeben. Forscher zeigten jedoch, dass die Filter genug Daten preisgaben, um Nutzer zu deanonymisieren, weshalb Bitcoin Core deren Bereitstellung 2019 standardmäßig abschaltete. Neuere Light Clients setzen auf Compact Block Filters (BIP 157/158), bei denen Full Nodes pro Block einen Filter veröffentlichen und Clients diesen lokal prüfen, statt einen Server abzufragen.

SPV bleibt überall dort attraktiv, wo Speicherplatz oder Bandbreite knapp sind, bringt aber echte Kompromisse mit sich: Ein Client, der nur mit unehrlichen Peers verbunden ist, kann eine erfundene, aber intern konsistente Kette vorgesetzt bekommen, und die Aufnahme in einen Block ist nicht dasselbe wie Finalität, da eine Transaktion durch eine tiefe Chain Reorganization noch rückgängig gemacht werden kann. Das Abwarten mehrerer Bestätigungen verringert dieses Risiko, beseitigt es aber nie vollständig.