Mike Hearn ist Bitcoin-Entwickler und Mitautor mehrerer BIPs, also Dokumente zu vorgeschlagenen technischen Lösungen. Er beteiligte sich an der Bibliothek bitcoinj sowie an Verfahren zur Prüfung von Verbindungen, zur Auswahl relevanter Transaktionen und zur Kommunikation beim Bezahlen. Sein Beitrag wird verständlicher, wenn man einer Zahlung von der Handy-Wallet bis zum Händler folgt.
Wer eine Bitcoin-Wallet entwickelt, muss nicht ihre gesamte Kommunikation selbst neu programmieren. Dafür gibt es Bibliotheken: Sammlungen fertiger Funktionen, auf denen eine Anwendung aufbauen kann. bitcoinj ist eine solche Bibliothek. Ihre Datei AUTHORS nennt Mike Hearn neben vielen anderen Mitwirkenden und verweist auf die Änderungshistorie in Git. Dort lassen sich einzelne Beiträge nachvollziehen. Das bedeutet weder, dass Hearn sämtliche Funktionen allein geschrieben hat, noch, dass er das gesamte Projekt heute leitet. [1]
bitcoinj ist eine Java-Bibliothek, mit der sich eine Wallet verwalten und Transaktionen senden oder empfangen lassen, ohne Bitcoin Core lokal zu installieren. Für ein Handy ist SPV, kurz für Simplified Payment Verification, interessant: Dieser Modus arbeitet mit Block-Headern und walletrelevanten Transaktionen, statt jede Transaktion vollständig zu prüfen. Das spart Daten und Geräteressourcen. Die Dokumentation beschreibt auch eine experimentelle vollständige Prüfung. Es handelt sich um unterschiedliche Modi; weniger Aufwand bedeutet nicht, dass sämtliche Regeln einfach nur schneller auf dieselbe Weise geprüft werden. [2]
Stellen wir uns einen Laptop vor, der aus dem Ruhezustand aufwacht. Die Verbindung zu einem anderen Knoten kann offen erscheinen, obwohl sie nicht mehr funktioniert. Hearns BIP 31 ermöglicht einen ping mit einer nonce, hier einer Zahl zur Kennzeichnung einer bestimmten Anfrage. Die Gegenstelle sendet dieselbe Zahl in einer pong-Nachricht zurück. Bei Protokollversionen über 60000 lassen sich so Antworten zuordnen und Reaktionszeiten messen. Geprüft wird die Kommunikation: Eine Antwort allein beweist weder die Ehrlichkeit des Knotens noch die Gültigkeit einer Zahlung. [3]
Warum sollte ein Handy Transaktionen herunterladen, die es gar nicht betreffen? BIP 37 von Hearn und Matt Corallo beschreibt einen Bloom-Filter, ein kompaktes Hilfsmittel zur Auswahl möglicher Treffer. filterload setzt den Filter, filteradd ergänzt einen Eintrag und filterclear entfernt den Filter. Dabei kann auch eine unbeteiligte Transaktion durchkommen; das ist ein falsch positiver Treffer. Ein genauerer Filter spart Daten, kann es der Gegenstelle aber erleichtern, Transaktionen mit der IP-Adresse der Wallet zu verknüpfen. Weniger Datenverkehr bedeutet daher nicht automatisch mehr Privatsphäre. [4]
Das Handy muss feststellen können, ob eine empfangene Transaktion zu einem bestimmten Block gehört. Die Nachricht merkleblock aus BIP 37 liefert die Daten für einen Merkle-Beweis: Einige Datenfingerabdrücke, sogenannte Hashes, reichen aus, um die Verbindung der Transaktion zum gemeinsamen Fingerabdruck im Block-Header zu prüfen. Der ganze Block muss dafür nicht heruntergeladen werden. Der Beweis schließt jedoch nicht aus, dass die Gegenstelle andere Transaktionen verschweigt. SPV ersetzt auch keine vollständige Gültigkeitsprüfung. Die bitcoinj-Dokumentation erklärt das Risiko, wenn ein Angreifer alle Wallet-Verbindungen kontrolliert und bestimmt, was sie zu sehen bekommt. [4] [5]
Beim Einkauf müssen Betrag und Empfänger klar sein. BIP 70 von Gavin Andresen und Hearn führt dafür PaymentRequest ein. Die Nachricht enthält Zahlungsdetails: Ausgänge, die festlegen, wohin die Transaktion Geld zuordnen soll, den Betrag und gegebenenfalls ein Ablaufdatum. X.509-Zertifikate können die Identität des Händlers bestätigen, ähnlich wie bei Webservern. Das Protokoll erlaubt aber auch pki_type none, eine Anfrage ohne diese Authentifizierung. Das Format einer Zahlungsanforderung allein belegt deshalb noch keine bestätigte Händleridentität. [6]
Gibt die Anfrage einen Zahlungsserver an, sendet die Wallet ihm nach der Freigabe eine Payment-Nachricht. Die Antwort PaymentACK kann mitteilen, dass der Händler die Zahlung zur Bearbeitung angenommen hat. Für den Kunden ist das hilfreich, bleibt aber eine Aussage des Händlerservers und kein Beweis für eine Bestätigung im Block. Ebenso nennt refund_to lediglich ein Ziel für eine mögliche Rückzahlung; das Feld zahlt selbst nichts zurück. Die Anwendung muss Nachrichten über eine Zahlung vom tatsächlichen Geldfluss unterscheiden. [6]
Eine ältere Anleitung kann den Eindruck erwecken, ihr Verfahren müsse überall funktionieren. BIP 70 ist im Register als Deployed gekennzeichnet, also als umgesetzt. Die Versionshinweise zu Bitcoin Core 0.20.0 dokumentieren jedoch die vollständige Entfernung seiner Unterstützung aus diesem Programm. Das widerspricht sich nicht: Eine früher genutzte Spezifikation muss nicht von jedem heutigen Client unterstützt werden. Hearns Arbeit erklärt einen Teil der Wallet-Entwicklung; für die praktische Anwendung müssen außerdem die Möglichkeiten des konkreten Programms und seiner Version geprüft werden. [6] [7]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Jeff Garzik, Gloria Zhao, Merkle Tree. Auf diesen Eintrag verweisen außerdem Jeff Garzik, Gloria Zhao.