Bitcoin Light Wallets erklärt: BIP 157/158, SPV und Compact Block Filters
Ein Bitcoin-Wallet muss herausfinden, welche Transaktionen zu Deinen Schlüsseln gehören. Auf einem Computer mit vollständigem Bitcoin-Node ist das vergleichsweise klar: Der Node lädt Blockchain-Daten, prüft die Konsensregeln und stellt der Wallet geprüfte Informationen zur Verfügung. Auf einem Smartphone sind Speicherplatz, Datenvolumen und Rechenleistung begrenzt. Viele Wallets arbeiten deshalb als Light Clients und beschaffen nur ausgewählte Informationen aus dem Bitcoin-Netzwerk. Doch diese Bequemlichkeit hat Folgen für Datenschutz, Verifikation und Vertrauen.
In diesem Fachartikel geht es um eine spezielle Lösung: Compact Block Filters nach BIP 157 und BIP 158. Du lernst, weshalb diese Standards entwickelt wurden, wie eine Wallet damit Transaktionen findet und wo die Grenzen liegen. Das Thema ist bewusst von der allgemeinen Wallet-Einrichtung, dem Seed-Backup und dem Bitcoin-Kauf abgegrenzt. Auch wenn eine Light Wallet Deine privaten Schlüssel selbst verwaltet, kann sie für die Blockchain-Abfrage auf fremde Datenquellen angewiesen sein. Genau diesen oft übersehenen Unterschied betrachten wir im Detail.
Was bedeutet Light Wallet bei Bitcoin?
Ein Light Wallet ist ein Bitcoin-Client, der nicht alle Blockchain-Daten vollständig herunterlädt und eigenständig validiert. Stattdessen verwendet er ausgewählte Informationen, etwa Blockheader, Merkle-Nachweise, Serverauskünfte oder kompakte Blockfilter. Die genaue Methode unterscheidet sich zwischen Wallet-Anwendungen. Es gibt deshalb keinen einheitlichen Sicherheitsgrad, den das Etikett «Light Wallet» automatisch garantiert. Für eine fundierte Beurteilung musst Du das konkrete Synchronisationsverfahren kennen.
Zwei Eigenschaften sind getrennt zu bewerten. Die erste betrifft die Verwahrung: Liegen die privaten Schlüssel auf Deinem Gerät oder bei einem Dienstleister? Die zweite betrifft die Verifikation: Wer entscheidet, ob ein angezeigter Bitcoin-Kontostand tatsächlich durch gültige Blockchain-Daten gedeckt ist? Eine Wallet kann vollständig selbstverwahrend sein und trotzdem für die Transaktionshistorie einem fremden Server vertrauen. Die Kontrolle über Schlüssel und die unabhängige Prüfung der Blockchain sind zwei unterschiedliche Sicherheitsdimensionen.
Wenn Du die kryptografischen Grundlagen verstehen möchtest, lies ergänzend unseren Beitrag über Private Keys und Public Keys bei Bitcoin. Die Alternative zu fremden Datenquellen ist ein eigener Bitcoin Full Node. Dort kannst Du die geltenden Regeln selbst prüfen, benötigst aber zusätzliche Ressourcen und eine funktionierende Konfiguration.
Welche Daten benötigt eine Wallet?
Ein Wallet kennt nicht bloss eine einzige Adresse. Moderne HD-Wallets können zahlreiche Empfangsadressen und Wechselgeldadressen erzeugen. Nach einer Wiederherstellung muss die Software gegebenenfalls ältere Ableitungspfade und verschiedene Skripttypen durchsuchen. Sie muss erkennen, wann ein relevanter Transaktionsausgang entstanden ist, ob dieser später ausgegeben wurde und wie viele Bestätigungen die zugehörige Transaktion besitzt. Ein vereinfachter Client benötigt dafür einen verlässlichen Suchmechanismus.
Bitcoin besitzt kein zentrales Kontenbuch mit einem gespeicherten Saldo pro Nutzer. Der verfügbare Betrag ergibt sich aus noch nicht ausgegebenen Transaktionsausgängen, den UTXOs. Das erklärt unser Artikel über Bitcoin UTXOs, Inputs, Outputs und Wechselgeld. Eine Light Wallet muss daher relevante Blockchain-Ereignisse erkennen, bevor sie einen korrekten Saldo berechnen kann.
SPV: Vereinfachte Zahlungsprüfung statt Full Node
Satoshi Nakamotos Bitcoin-Whitepaper beschreibt Simplified Payment Verification, kurz SPV. Dabei prüft ein Client unter anderem Blockheader und kann mit Merkle-Nachweisen nachvollziehen, dass eine Transaktion in einem bestimmten Block enthalten ist. Blockheader sind deutlich kleiner als vollständige Blöcke. Das macht es möglich, einen Teil der Blockchain-Sicherheit mit geringerem Datenaufwand zu nutzen.
Ein Merkle-Nachweis bestätigt jedoch nicht eigenständig, dass sämtliche Transaktionen des betreffenden Blocks alle Bitcoin-Konsensregeln erfüllen. Ein vollständig validierender Node überprüft viel mehr: etwa die Gültigkeit der Ausgaben, die Blockstruktur und weitere Regeln. SPV arbeitet dagegen mit Annahmen über die von anderen Teilnehmern validierte Proof-of-Work-Kette. Die Methode ist nicht grundsätzlich wertlos, aber ihr Sicherheitsmodell darf nicht mit dem eines Full Nodes verwechselt werden.
Auch die Anzahl der Bestätigungen löst diese Unterscheidung nicht auf. Mehr Bestätigungen erhöhen unter bestimmten Annahmen die Schwierigkeit, eine Transaktion durch eine alternative Kette zu verdrängen. Sie verwandeln eine unvollständige lokale Prüfung aber nicht in eine vollständige Konsensvalidierung. Mehr dazu erfährst Du in unserem Beitrag Bitcoin-Bestätigungen: 0, 1, 3 oder 6.
Das ältere Verfahren: Bloom-Filter nach BIP 37
Bei einem älteren Ansatz, der in BIP 37 beschrieben ist, erzeugt der Client einen Bloom-Filter und übermittelt ihn an einen verbundenen Bitcoin-Node. Der Node verwendet diesen Filter, um möglicherweise passende Transaktionen zu suchen. Der Filter enthält keine gewöhnliche Liste der Adressen im Klartext. Er erlaubt absichtlich falsche Treffer, damit sich nicht jede Antwort eindeutig einem bestimmten Interesse zuordnen lässt.
Das klingt zunächst datensparsam. In der Praxis können Bloom-Filter aber Informationen über die Suchinteressen des Clients verraten. Werden Filter aktualisiert oder wiederholt übermittelt, können Beobachter Unterschiede auswerten. Die Verbindung mit IP-Adressen, Zeitpunkten und weiteren Daten verschärft das Problem. Die Filter schützen deshalb nicht automatisch vor der Verknüpfung mehrerer Bitcoin-Adressen zu einer Wallet.
Hinzu kommt die Belastung des Servers. Bei BIP 37 muss ein Full Node auf Basis der clientseitigen Filter passende Daten suchen. Ein Angreifer kann versuchen, über viele oder ungünstige Abfragen unverhältnismässig viel Arbeit zu verursachen. BIP 157 nennt sowohl diese asymmetrische Belastung als auch die Datenschutzschwächen als wesentliche Gründe für einen anderen Ansatz. Die historische Konstruktion ist in der offiziellen BIP-37-Spezifikation dokumentiert.
Die entscheidende Umkehrung des Suchprinzips
BIP 37 lässt den Server nach den Interessen des Clients suchen. Bei BIP 157/158 erstellt der Server dagegen standardisierte Filter für die Blöcke und übermittelt sie dem Client. Dieser gleicht die Filter lokal mit seinen eigenen Skripten ab. Der Server muss also nicht erst erfahren, welche konkreten Skripte der Client überwacht. Das ist der grundlegende Datenschutzvorteil des neuen Verfahrens.
Dieser Vorteil ist allerdings nicht grenzenlos. Wenn die Wallet später ausschliesslich diejenigen vollständigen Blöcke abruft, die zu ihren Skripten passen, kann ein Beobachter aus dem Abrufmuster Vermutungen ableiten. Ein Filterprotokoll schützt vor einer bestimmten Form der direkten Offenlegung, nicht vor sämtlicher Netzwerküberwachung. Deshalb sind unabhängige Peers und die Gestaltung der nachfolgenden Datenabrufe ebenfalls wichtig.
Bei der Wahl einer Bitcoin-App solltest Du folglich zwischen Kauf, Verwahrung und Synchronisation unterscheiden. Eine App kann eine einfache Kaufoberfläche bieten, ohne dass damit automatisch feststeht, welches technische Filterprotokoll ihre Wallet nutzt. Auch die Bezeichnung «non-custodial» beschreibt in erster Linie die Schlüsselkontrolle und nicht zwangsläufig den Datenschutz der Blockchain-Abfragen.
BIP 157 und BIP 158: Was regelt welcher Standard?
BIP 157 definiert das Peer-to-Peer-Protokoll für die Abfrage kompakter Blockfilter. Es beschreibt Nachrichten, Filterheader, Kontrollpunkte und Empfehlungen für Light Clients. BIP 158 legt dagegen die Filterkonstruktion fest, einschliesslich des grundlegenden Filtertyps. Beide Standards greifen ineinander: Die Wallet benötigt sowohl ein gemeinsames Filterformat als auch ein Verfahren, um die Filter zu beziehen und deren Konsistenz zu beurteilen.
Die Autoren beschreiben das Verfahren in BIP 157: Client Side Block Filtering und BIP 158: Compact Block Filters for Light Clients. Es handelt sich um Spezifikationen für die Peer-Kommunikation und Datenstruktur. Sie verändern nicht die Bitcoin-Konsensregeln. Deshalb ist es falsch, Compact Block Filters als neue Art von Bitcoin-Transaktion oder als eigenes Zahlungsnetzwerk darzustellen.
So funktioniert die Synchronisation Schritt für Schritt
Zunächst lädt die Wallet Blockheader und bewertet die Proof-of-Work-Kette nach ihrem Prüfmodell. Anschliessend bezieht sie Filterheader und kompakte Filter für die Blöcke, die sie untersuchen möchte. Die eigenen Wallet-Skripte werden lokal gegen diese Filter getestet. Wenn ein Filter einen möglichen Treffer meldet, beschafft die Wallet weitere Blockchain-Daten, häufig den vollständigen Block, und untersucht die enthaltenen Transaktionen.
Danach aktualisiert die Wallet die Liste der relevanten UTXOs und beobachtet neu hinzukommende Blöcke. Bei einer Reorganisation muss sie ihre bisherige Sicht gegebenenfalls korrigieren. Das Verfahren eignet sich somit nicht nur für die erstmalige Wiederherstellung, sondern auch für die laufende Überwachung. Die konkrete Software muss allerdings alle Schritte korrekt implementieren; die Existenz einer technischen Spezifikation garantiert keine fehlerfreie Wallet.
Beispiel einer wiederhergestellten Wallet
Angenommen, Du stellst nach einem Gerätewechsel eine Wallet wieder her, die über mehrere Jahre 30 Empfangs- und Wechselgeldskripte verwendet hat. Bei einem personalisierten Serververfahren könnte die Anwendung diese Skripte an einen Server schicken und um die zugehörige Historie bitten. Mit Compact Block Filters kann sie stattdessen Filter für die relevanten Blöcke laden und lokal nach möglichen Treffern suchen.
Das bedeutet nicht, dass eine Wallet automatisch alle alten Adressen findet. Sie muss die richtigen Ableitungspfade, Skripttypen und gegebenenfalls weitere Metadaten kennen. Gerade bei komplexen Wallet-Konfigurationen kann ein Seed allein nicht sämtliche benötigten Informationen enthalten. Die Hintergründe erklären wir im Beitrag über Wallet Descriptors, xpub und Backups.
Golomb-Coded Sets: Wie werden Filter so kompakt?
BIP 158 verwendet Golomb-Coded Sets, abgekürzt GCS. Vereinfacht gesagt werden die für einen Block relevanten Skriptdaten zunächst mit einer Hashfunktion auf Zahlen abgebildet. Die Zahlen werden sortiert. Anschliessend speichert der Filter nicht jeden vollständigen Zahlenwert, sondern komprimiert die Differenzen zwischen aufeinanderfolgenden Werten. Dieses Verfahren spart Platz, weil die Differenzen effizient codiert werden können.
Für den Basic-Filter sind die Parameter P = 19 und M = 784931 festgelegt. Sie beeinflussen die Codierung und die Wahrscheinlichkeit falscher Treffer. Die Konstruktion ist deterministisch: Verschiedene korrekt arbeitende Nodes sollten für denselben Block denselben Basic-Filter erzeugen. Dadurch können Clients Antworten unterschiedlicher Peers miteinander vergleichen und Unstimmigkeiten erkennen.
Welche Daten sind im Basic-Filter enthalten?
Der Basic-Filter enthält die ScriptPubKeys der Ausgänge eines Blocks, mit der in BIP 158 festgelegten Ausnahme für OP_RETURN-Ausgänge. Ausserdem berücksichtigt er die vorherigen Ausgabeskripte der verbrauchten Transaktionsinputs, abgesehen von der besonderen Coinbase-Transaktion. Diese Zusammensetzung hilft einer Wallet, sowohl eingehende Zahlungen als auch das spätere Ausgeben bereits beobachteter Ausgänge zu erkennen.
Der Filter speichert keine Klartextliste von Nutzernamen, Wallet-Konten oder vollständigen Transaktionen. Er ist ein komprimiertes Suchinstrument für Skriptdaten. Eine Bitcoin-Adresse ist lediglich eine menschenlesbare Darstellung bestimmter Ausgabebedingungen. Die Wallet muss daher die relevanten Skripte kennen und darf die Blockchain-Suche nicht mit einer einfachen Kontonummernabfrage verwechseln.
Falsche Treffer und die mathematische Wahrscheinlichkeit
Ein GCS-Filter ist probabilistisch. Er kann bei einem Element, das nicht enthalten ist, trotzdem einen Treffer melden. Für den Basic-Filter ergibt sich aus M = 784931 eine ungefähre False-Positive-Wahrscheinlichkeit von 1/784931 pro nicht enthaltenem Suchwert, also rund 0,0001274 Prozent. Das ist eine rechnerische Filtereigenschaft, keine allgemeine Wahrscheinlichkeit für eine falsche Wallet-Bilanz.
Bei einem falschen Treffer lädt die Wallet möglicherweise einen Block, der keine relevante Transaktion enthält. Nach der tatsächlichen Prüfung wird der Irrtum erkannt. Der Preis ist zusätzlicher Datenverkehr. Ein korrekt erstellter Filter soll dagegen tatsächlich enthaltene Elemente nicht übersehen. Diese Aussage gilt nicht automatisch für einen böswillig manipulierten Filter, den ein unehrlicher Peer ausliefert.
Filterheader: Wie werden Manipulationen erkennbar?
BIP 157 definiert Filterheader, die kryptografisch miteinander verkettet sind. Ein Filterheader hängt vom Hash des aktuellen Filters und vom vorherigen Filterheader ab. Wenn ein Peer einen anderen Filter liefert als zuvor angekündigt, entsteht ein Widerspruch. Ein Client kann dann weitere Peers befragen und bei Bedarf den betreffenden Block genauer untersuchen.
Die Einschränkung ist entscheidend: Diese Filterheader sind nicht als Konsensverpflichtung in den gewöhnlichen Bitcoin-Blockheadern verankert. Ein einzelner böswilliger Peer kann deshalb eine isolierte Wallet nicht allein durch das Vorhandensein einer Filterheader-Kette zur korrekten Sicht zwingen. Der Schutz baut auf unabhängigen Datenquellen, Vergleichen und der Möglichkeit auf, strittige Informationen zu prüfen.
BIP 157 empfiehlt unter anderem, Filterheader von mehreren Peers zu vergleichen und bei widersprüchlichen Angaben zusätzliche Prüfungen durchzuführen. Eine Wallet, die solche Empfehlungen nicht umsetzt oder nur einen kontrollierten Peer erreicht, kann weiterhin unvollständige Informationen erhalten. Die Sicherheitsqualität hängt daher nicht nur vom Standard, sondern auch von der konkreten Implementierung und Netzwerkumgebung ab.
Kann ein Angreifer eine Zahlung verstecken?
Ein manipulierter Server kann versuchen, eine relevante Transaktion aus der Wallet-Sicht verschwinden zu lassen oder unzutreffende Filter zu liefern. Wenn die Wallet unabhängige ehrliche Peers erreicht, können Widersprüche auffallen. Sind sämtliche Verbindungen kontrolliert, beispielsweise durch einen Eclipse-Angriff, bleiben Risiken für die Verfügbarkeit und die Richtigkeit der angezeigten Informationen.
Auch die Abwehr eines 51-Prozent-Angriffs ist ein anderes Thema. Mining-Mehrheit, Konsensvalidierung und Netzwerkisolation sind nicht identisch. Compact Block Filters verändern weder die Hashrate-Verteilung noch die Bitcoin-Konsensregeln. Sie sollen eine effizientere und datenschutzfreundlichere Suche nach Wallet-relevanten Blockchain-Ereignissen ermöglichen.
Datenschutz: Was sieht der Filteranbieter noch?
Der wichtigste Vorteil ist die lokale Suche. Der Filteranbieter erhält nicht unmittelbar die Liste der beobachteten Wallet-Skripte. Trotzdem sieht ein Netzwerkpartner möglicherweise Deine IP-Adresse, Verbindungszeiten, angeforderte Blockbereiche und technische Merkmale der Clientsoftware. Diese Metadaten können in Kombination mit weiteren Beobachtungen aussagekräftig werden. Der Begriff «privat» darf deshalb nicht als «unsichtbar» verstanden werden.
Besonders interessant sind die nachgelagerten Blockdownloads. Wenn ein Client nur die wenigen Blöcke herunterlädt, bei denen er einen Filtertreffer entdeckt hat, könnte der liefernde Peer daraus auf mögliche Interessen schliessen. Werden Daten von unterschiedlichen Peers bezogen oder zusätzliche Schutzmassnahmen verwendet, kann die Zuordnung schwieriger werden. Eine Garantie vollständiger Anonymität entsteht dadurch jedoch nicht.
Hinzu kommt die Transparenz der Bitcoin-Blockchain. Adresswiederverwendung, verknüpfte Transaktionsausgänge und öffentlich bekannte Zahlungen können die Identität eines Nutzers offenlegen, selbst wenn seine Wallet sehr datensparsam synchronisiert. Unser Artikel über Bitcoin-Datenschutz und Blockchain-Analyse behandelt diese zusätzliche Ebene ausführlich.
Kaufdaten bleiben Kaufdaten
Beim Kauf über einen regulierten Dienst können Identifikations-, Zahlungs- und Transaktionsdaten entstehen. Eine spätere Synchronisation mit BIP 157/158 löscht solche Daten nicht. Ebenso wenig verhindert sie, dass Du selbst eine Transaktions-ID öffentlich machst oder mehrere UTXOs in einer Weise kombinierst, die Rückschlüsse ermöglicht. Datenschutz muss daher entlang des gesamten Weges betrachtet werden: Kauf, Auszahlung, Wallet-Synchronisation, Transaktionsgestaltung und Netzwerkverbindung.
Eine datensparsame Wallet ist nur ein Baustein. Wer hohe Datenschutzanforderungen hat, sollte die Dokumentation der verwendeten Software und deren tatsächliche Datenflüsse prüfen. Weder die Bezeichnung «Open Source» noch «Self-Custody» oder «Bitcoin only» beweist für sich allein, dass BIP 157/158 genutzt wird.
Full Node, zentraler Server oder Compact Filters?
Ein eigener Full Node validiert Blockchain-Daten nach den von Dir betriebenen Bitcoin-Regeln. Er kann die Wallet mit selbst geprüften Informationen versorgen und reduziert die Abhängigkeit von fremden Auskunftsdiensten. Dafür benötigt er Speicherplatz, Bandbreite, Strom und Wartung. Eine zentral angebundene Wallet ist oft bequemer, kann aber ihre Suchinteressen direkt an den Betreiber offenlegen und dessen Antworten nicht vollständig selbst überprüfen.
Compact Block Filters bilden einen Mittelweg. Sie benötigen weniger Ressourcen als eine vollständige Blockchain-Validierung und vermeiden die direkte Übertragung der Skriptliste an den Filteranbieter. Dennoch muss der Client Filter, Blockdaten und Netzwerkpartner sorgfältig behandeln. Die Entscheidung ist daher nicht einfach «sicher» gegen «unsicher», sondern eine Abwägung verschiedener Vertrauensannahmen und technischer Anforderungen.
Eine Hardware Wallet verändert diesen Vergleich nur teilweise. Sie schützt in erster Linie die privaten Schlüssel und den Signiervorgang. Die begleitende Software kann trotzdem einen zentralen Server verwenden. Wer Schlüsselisolation und unabhängige Blockchain-Prüfung kombinieren möchte, kann eine Hardware Wallet mit einem eigenen Full Node betreiben. Das ist aufwendiger, trennt aber beide Sicherheitsaufgaben klar.
Bitcoin Core und die praktische Unterstützung
Die offizielle Bitcoin-Core-Übersicht dokumentiert, dass Compact Block Filters seit Version 0.19.0 indexiert und seit Version 0.21.0 über das Peer-to-Peer-Netzwerk bereitgestellt werden können. Daraus folgt nicht, dass jeder beliebige Node automatisch die benötigten Filter ausliefert. Konfiguration, Indexierung, Softwareversion und Netzwerkerreichbarkeit spielen eine Rolle.
Für technische Prüfungen existiert der RPC-Befehl getblockfilter. Er kann für einen Blockhash den hexadezimal codierten Basic-Filter und den Filterheader liefern, sofern die notwendigen Daten verfügbar sind. Das ist eine Diagnosefunktion und keine gewöhnliche Bedienoberfläche für Einsteiger. Die Details findest Du in der Bitcoin-Core-Dokumentation zu BIPs sowie in der RPC-Referenz getblockfilter.
Ein selbst betriebener Node sollte nicht ohne Verständnis seiner Netzwerkeinstellungen für beliebige externe Zugriffe geöffnet werden. Wer einen mobilen Client an den eigenen Node anbinden möchte, sollte die dokumentierten und unterstützten Verbindungsmethoden der verwendeten Wallet prüfen. Nicht jede Wallet unterstützt jede Serverarchitektur, und die blosse Existenz des Filterindexes garantiert noch keine funktionierende Verbindung.
So überprüfst Du Deine eigene Bitcoin-Wallet
Prüfe zuerst die offizielle Dokumentation Deiner Wallet. Suche gezielt nach BIP 157, BIP 158, Compact Block Filters, Neutrino, Electrum-Server, Full-Node-Anbindung oder einer zentralen Blockchain-API. Die Bezeichnung «dezentrale Wallet» reicht als technischer Nachweis nicht aus. Auch eine Wallet mit lokalen Schlüsseln kann ihre Transaktionshistorie von einem zentralen Dienst beziehen.
Prüfe anschliessend, ob Du die verwendeten Peers oder Server konfigurieren kannst. Ein eigener Node kann die direkte Offenlegung von Adressabfragen gegenüber einem fremden Anbieter reduzieren, sofern die Verbindung korrekt eingerichtet ist. Bedenke aber, dass andere App-Funktionen weiterhin Daten übertragen können. Eine vollständige Datenschutzprüfung muss deshalb mehr umfassen als die Einstellung eines einzigen Servers.
Prüfe schliesslich die Wiederherstellung. Ein sicher verwahrter Seed ist wichtig, aber je nach Wallet-Konfiguration können Ableitungspfade und weitere Metadaten nötig sein. Die Filtertechnik löst solche Backup-Fragen nicht. Lies dazu unseren Beitrag Bitcoin Seed Phrase sichern und wiederherstellen. Teste eine Wiederherstellung nur mit geeigneten Sicherheitsvorkehrungen und gib Deine Seed-Wörter niemals auf einer unbekannten Webseite ein.
Relai als Kaufoption in der Schweiz
Relai bietet eine Möglichkeit, Bitcoin über eine App zu kaufen. Die hier erklärte Filtertechnik ist davon zu unterscheiden: Aus diesem Artikel folgt ausdrücklich nicht, dass jede Komponente der Relai-App BIP 157/158 einsetzt. Wer den Dienst nutzt, sollte die aktuellen Kaufbedingungen, Gebühren, Wechselkurse, Verwahrungsdetails und Möglichkeiten zur Auszahlung prüfen. Die technische Beurteilung der Wallet darf nicht durch die Bequemlichkeit des Kaufs ersetzt werden.
Werbung / Affiliate-Link: Wenn Du Relai als Anbieter prüfen möchtest, verwende bei Relai ausdrücklich unseren Code AUSWANDERNSCHWEIZ. Über unseren Partnerlink kann eine Provision für Auswandern Schweiz entstehen. Wir versprechen keinen Gewinn und keinen Bonus, dessen Bedingungen nicht aktuell überprüft sind. Die verbindlichen Kosten ergeben sich aus den zum Kaufzeitpunkt angezeigten Konditionen. Die offizielle Relai-Gebührenübersicht wurde am 15. Juli 2026 aktualisiert.
Bitcoin unterliegt erheblichen Kursschwankungen. Du kannst einen grossen Teil des eingesetzten Geldes verlieren. Bei eigener Verwahrung besteht ausserdem das Risiko, den Zugang durch verlorene Schlüssel, beschädigte Backups oder Fehlüberweisungen dauerhaft einzubüssen. Bei externen Dienstleistern können zusätzliche Gegenpartei- und Betriebsrisiken entstehen. Keine dieser Gefahren wird durch Compact Block Filters beseitigt.
Unser Relai-Testbericht behandelt den Kaufdienst ausführlicher. Dieser Artikel konzentriert sich bewusst auf die technische Frage, wie Light Wallets Blockchain-Daten finden und welche Datenschutz- und Sicherheitsannahmen damit verbunden sind.
Häufige Fragen zu Bitcoin Light Wallets
Sind SPV und Compact Block Filters dasselbe?
Nein. SPV beschreibt einen Ansatz der vereinfachten Zahlungsprüfung mit Blockheadern und Nachweisen. Compact Block Filters sind ein Verfahren, mit dem eine Wallet relevante Blöcke finden kann, ohne ihre Skriptliste direkt an den Filteranbieter zu schicken. Die beiden Konzepte können sich ergänzen, sind aber nicht identisch. Eine Wallet kann auch ganz andere Serverprotokolle verwenden.
Ist BIP 157/158 vollständig anonym?
Nein. Der Filteranbieter erfährt nicht unmittelbar, nach welchen Skripten die Wallet lokal sucht. IP-Adressen, Zeitpunkte, Blockabrufe und öffentliche Blockchain-Informationen können trotzdem Hinweise liefern. Auch Daten, die beim Kauf entstanden sind, bleiben bestehen. Das Verfahren verbessert einen bestimmten Aspekt des Datenschutzes, ohne sämtliche anderen Informationsquellen zu beseitigen.
Können Filter einen echten Eingang übersehen?
Ein korrekt konstruierter Basic-Filter soll die spezifizierten enthaltenen Skripte erfassen. Falsche positive Treffer sind möglich und beabsichtigt. Ein manipulierter, fehlerhafter oder unvollständig gelieferter Filter ist jedoch ein anderes Problem. Deshalb sind die Kontrolle der Filterheader, unabhängige Peers und die Prüfung nachgeladener Blockchain-Daten wichtig.
Wie hoch ist die False-Positive-Rate?
Für den Basic-Filter verwendet BIP 158 M = 784931. Die rechnerische Wahrscheinlichkeit eines falschen Treffers für einen einzelnen nicht enthaltenen Suchwert beträgt ungefähr 1/784931. Bei vielen Abfragen können zusätzliche Treffer auftreten. Das ist keine allgemeine Fehlerquote einer Wallet und sagt nichts darüber aus, ob eine Zahlung tatsächlich gültig ist.
Warum lädt die Wallet bei Treffern ganze Blöcke?
Der Filter enthält keine vollständigen Transaktionsdaten. Er zeigt lediglich einen möglichen Bezug zu bestimmten Skripten an. Die Wallet benötigt weitere Daten, um tatsächliche Ein- und Ausgänge zu erkennen. Ganze Blockdownloads können die direkte Preisgabe einzelner Transaktionsinteressen reduzieren, verursachen aber mehr Datenverkehr und können ihrerseits beobachtet werden.
Kann ein böswilliger Server meinen Kontostand manipulieren?
Ein böswilliger Server kann versuchen, Informationen zurückzuhalten oder falsche Antworten zu liefern. BIP 157 sieht Vergleiche und Prüfmechanismen vor, deren Wirksamkeit von unabhängigen Peers und einer korrekten Implementierung abhängt. Ein isolierter Client ist weiterhin angreifbar. Ein eigener vollständig validierender Node reduziert die Abhängigkeit von solchen Serverantworten erheblich.
Brauche ich einen Full Node für eine Hardware Wallet?
Nicht zwingend. Eine Hardware Wallet kann mit verschiedenen Softwareoberflächen und Datenquellen arbeiten. Sie schützt primär die Schlüssel. Ein Full Node ergänzt die unabhängige Blockchain-Prüfung, ist aber mit zusätzlichem Aufwand verbunden. Welche Kombination sinnvoll ist, hängt von Deinem Sicherheitsbedarf und Deinen technischen Möglichkeiten ab.
Kann Lightning BIP 157/158 verwenden?
Lightning-Anwendungen müssen teilweise auch On-Chain-Ereignisse beobachten, etwa bei Kanalöffnungen oder -schliessungen. Compact Block Filters können für bestimmte Implementierungen ein technischer Baustein sein. Das bedeutet jedoch nicht, dass jede Lightning-Wallet dieses Protokoll verwendet. Die tatsächliche Architektur muss anhand der jeweiligen Dokumentation geprüft werden.
Zusammenfassung
BIP 157 und BIP 158 erlauben Bitcoin Light Wallets, standardisierte Blockfilter herunterzuladen und die Suche nach relevanten Skripten lokal auszuführen. Gegenüber älteren personalisierten Bloom-Filter-Abfragen kann das die Privatsphäre verbessern. Golomb-Coded Sets reduzieren den Datenumfang, während Filterheader und Peer-Vergleiche bei der Erkennung widersprüchlicher Daten helfen. Trotzdem ersetzen sie keine vollständige Blockchain-Validierung und garantieren keine Anonymität.
Für Dich zählen deshalb fünf getrennte Fragen: Wer kontrolliert Deine Schlüssel? Woher stammen Deine Blockchain-Daten? Wie werden sie geprüft? Welche Informationen verraten die Netzwerkverbindungen? Und wie sicher ist Deine Wiederherstellung? Wenn Du diese Punkte beantwortest, kannst Du Wallet-Angebote besser beurteilen, ohne Datenschutzversprechen oder technische Schlagworte mit tatsächlicher Sicherheit zu verwechseln.
Quellen und weiterführende Literatur
BIP 157: Client Side Block Filtering. Offizielle Spezifikation für Filterheader, Peer-Nachrichten und die Synchronisation von Light Clients.
BIP 158: Compact Block Filters for Light Clients. Offizielle Spezifikation des Basic-Filters, der GCS-Codierung und ihrer Parameter.
BIP 37: Connection Bloom Filtering. Historische technische Grundlage für den Vergleich mit älteren Bloom-Filtern.
Bitcoin Core: Implementierte BIPs. Offizielle Übersicht zur Unterstützung von BIP 157/158 in Bitcoin Core.
Bitcoin Core RPC: getblockfilter, Version 28.0. Referenz für die Ausgabe von Blockfiltern und Filterheadern.
Lightning Labs: Neutrino. Open-Source-Implementierungsreferenz eines Bitcoin Light Clients.
Relai: Offizielle Gebühreninformation, 15. Juli 2026. Anbieterquelle zur Einordnung der Kaufoption.
Kommentare