Bitcoin Core

Pavel verkauft Bücher gegen Bitcoin. Eine Kundin zeigt ihm die Zahlungsbestätigung auf ihrem Handy. Er möchte aber wissen, ob die Zahlung tatsächlich angekommen ist und in einem gültigen Block steht. Dafür kann er einen öffentlichen Blockexplorer abfragen oder eine Wallet mit seinem eigenen Node verbinden. Bitcoin Core ist die Software, mit der er diesen Node betreibt. Gemeint ist ein Computer mit Software, die Bitcoins Regeln eigenständig prüft. Ein Block bündelt Transaktionen, die der gemeinsamen Historie hinzugefügt werden. Sie bezieht Daten von anderen, beurteilt deren Gültigkeit jedoch selbst. Pavel ist ein anschauliches Beispiel: Statt nur einer fremden Anzeige zu vertrauen, prüft er die Daten selbst. Die Installation macht ihn weder zum Miner noch bringt sie ihm automatisch BTC oder die Macht, fremde Zahlungen rückgängig zu machen. Der Quellcode wird unter der MIT-Lizenz veröffentlicht und darf unter deren Bedingungen untersucht, verändert und weitergegeben werden. [1] [16]

Beide Aufgaben werden leicht verwechselt, weil Bitcoin Core beides übernehmen kann. Der Node prüft die Historie und neue Blöcke. Die Wallet verfolgt die zugehörigen Mittel, erzeugt Adressen und bereitet Transaktionen vor. Verwaltet sie private Schlüssel, kann sie damit auch signieren. Ein privater Schlüssel ist eine geheime Information, mit der die Wallet eine digitale Signatur zur Freigabe der zugehörigen Bitcoin erstellt. Der Schlüssel selbst wird dabei nicht an andere Nodes gesendet. Core läuft aber ebenso ohne Wallet. Pavel kann eine andere kompatible Zahlungsanwendung verwenden und seinen Node als Quelle geprüfter Daten nutzen; manche Verbindungen benötigen zusätzliche Software. Eine laufende Core-Instanz leitet andere Wallets nicht automatisch auf diesen Node um. Zur Orientierung: bitcoin-qt bietet eine grafische Oberfläche, bitcoind läuft im Hintergrund und bitcoin-cli übermittelt Befehle an das Programm. [12] [17]

Ein neuer Node muss zunächst die bisherige Geschichte aufholen. Das heißt Initial Block Download, kurz IBD. Bei der üblichen Synchronisierung lädt er Blöcke herunter und prüft ihre Verkettung, die Arbeit der Miner und die Transaktionsregeln. Daraus entsteht der chainstate: sein eigener Bestand noch nicht ausgegebener Transaktionsausgänge, der UTXOs. Ein Transaktionsausgang legt einen Betrag und die Bedingungen für dessen Ausgabe fest, etwa eine benötigte Signatur. Er bleibt in diesem Bestand, bis eine weitere Transaktion ihn ausgibt. Das ist kein Verzeichnis von Namen und Bankkonten. Die Geschwindigkeit hängt von Rechner, Datenträger und Verbindung ab; ein langsamer Start ist deshalb nicht automatisch ein Fehler. Vor der Prüfung aktueller Zahlungen wartet Pavel auf die abgeschlossene Synchronisierung.

Eine wichtige Präzisierung: assumevalid kann unter bestimmten Voraussetzungen Prüfungen der Skripte, also der Ausgabebedingungen, weit zurückliegender Blöcke überspringen; -assumevalid=0 deaktiviert diese Abkürzung. Eine andere Funktion, AssumeUTXO, ermöglicht den Start mit einem geprüften Zustandsabbild, während die ältere Historie im Hintergrund verarbeitet wird. Das Abbild hält den UTXO-Bestand bei einem bestimmten Block fest. Die Software vergleicht zunächst dessen Hash, einen digitalen Fingerabdruck, mit einem erwarteten Wert in ihrem Code. Damit ist die eigenständige Prüfung der gesamten früheren Historie noch nicht abgeschlossen. Beide Verfahren haben unterschiedliche Annahmen. Deshalb hat nicht jede Installation von Anfang an genau dieselben Prüfungen durchgeführt. [9] [10] [12] [17]

Nach der Synchronisierung empfängt Core weiter Daten von verbundenen Nodes, den Peers. Angenommene unbestätigte Transaktionen liegen im Mempool, seinem vorübergehenden Wartebereich. Das ist noch keine Bestätigung in einem Block; auch können die Mempools verschiedener Nodes unterschiedlich aussehen. Trifft ein neuer Block ein, prüft Core ihn. Unter gültigen Kandidatenketten entscheidet die größte angesammelte Arbeit, nicht eine Abstimmung der Computer oder bloß die Anzahl der Blöcke. Pavel unterscheidet daher zwischen „Zahlung gesehen“ und „Zahlung bestätigt“. Auch sein eigener Node garantiert keine sofortige Aufnahme und verhindert keine Reorganisation, bei der ein anderer gültiger Zweig einen Teil der zuvor verfolgten Historie ersetzt. [16]

Angenommen, Pavels Node nimmt eine unbestätigte Transaktion nicht in seinen Mempool auf. Daraus folgt nicht, dass sie niemals in einem gültigen Block erscheinen kann. Konsensregeln bestimmen gültige Blöcke und zulässige Ausgaben. Die lokale relay policy legt zusätzlich fest, welche unbestätigten Transaktionen der Node annimmt und weiterleitet, etwa zum Schutz vor Überlastung. Auf Transaktionen innerhalb eines empfangenen Blocks wird diese Policy nicht auf dieselbe Weise angewandt; dort zählt die Gültigkeit nach den Konsensregeln. Unterschiedliche Mempool-Einstellungen spalten deshalb nicht von sich aus das Netzwerk. Diese Unterscheidung hilft, Diskussionen über Core zu verstehen, ohne jede Einstellung mit einer Änderung der Geldregeln zu verwechseln. [13]

Core speichert Blockdaten, den Zustand des Nodes und gegebenenfalls Wallets. Pruning spart Platz, indem ältere Blockdateien und Daten zum Rückgängigmachen ihrer Änderungen nach der Verarbeitung gelöscht werden. Neue Blöcke prüft der Node weiterhin; nur das vollständige Archiv liegt nicht mehr vor. Historische Abfragen oder ein erneutes Durchsuchen alter Zahlungen können dann einen weiteren Download erfordern. Indizes beschleunigen bestimmte Suchvorgänge; txindex etwa ist mit Pruning nicht vereinbar. Die Auswahl richtet sich nach dem Einsatz des Nodes. Entscheidender ist: Öffentliche Blöcke lassen sich erneut herunterladen, verlorene private Schlüssel daraus aber nicht wiederherstellen. Eine Core-Wallet braucht ein eigenes, sicher aufbewahrtes Backup. Nutzen Sie bei laufendem Programm die Backup-Funktion, beispielsweise backupwallet, statt eine gerade beschriebene Datenbank beiläufig zu kopieren. [11] [12]

Pavel beginnt auf der offiziellen Website und liest die Anleitung zum gewählten Release. Eine SHA-256-Prüfsumme ist ein Fingerabdruck der heruntergeladenen Datei: Sie zeigt Abweichungen vom erwarteten Inhalt. Allein verrät sie jedoch nicht, wer den erwarteten Fingerabdruck veröffentlicht hat. Deshalb müssen auch digitale Signaturen und die Identität der Signaturschlüssel geprüft werden. Liefert ein Angreifer Programm und Prüfsumme zusammen, schützt deren Übereinstimmung nicht. Für eine weitergehende Kontrolle nutzt das Projekt reproduzierbare Builds: Unabhängige Personen können aus demselben Quellcode identische Dateien erstellen und ihre Ergebnisse vergleichen. Guix hilft, die dafür nötige Bauumgebung zu vereinheitlichen. Das stärkt die Herkunftsprüfung, beweist aber nicht, dass der Code fehlerfrei ist. [8] [7]

Über JSON-RPC können andere Programme Core steuern. Die Schnittstelle eignet sich für Statusabfragen und die Anbindung von Diensten, kann je nach Wallet und Berechtigungen aber auch Zugriff auf Mittel ermöglichen. Zugangsdaten gehören deshalb nicht in die Hände vermeintlicher Helfer. Die Schnittstelle verschlüsselt den Netzwerkverkehr nicht selbst und ist nicht für das öffentliche Internet ausgelegt. Normale Verbindungen zu Bitcoin-Nodes sind etwas anderes als die Freigabe dieser Steuerung. Für lokale Zugriffe verwendet Core auch vorübergehende Zugangsdaten in der Datei .cookie. Fernverwaltung braucht eine gesicherte Verbindung und begrenzten Zugriff gemäß Dokumentation. Wer einen Node erst ausprobiert, muss dafür keine Verwaltungsschnittstelle ins Internet öffnen. [14]

Jeder kann Codeänderungen vorschlagen. Andere Mitwirkende lesen, testen und diskutieren sie. Repository-Verwalter, die maintainers, können akzeptierte Änderungen zusammenführen. Damit erhalten sie keine Fernsteuerung über Pavels Node. Der Betreiber entscheidet, welche Software läuft. Diese Wahl ist aber auch kein Stimmzettel, mit dem ein Einzelner allen anderen neue Regeln vorschreibt: Eine inkompatible Änderung kann seinen Node vom Rest trennen. Bitcoin Core ist eine wichtige Implementierung der Regeln, kein Unternehmen, dem das gesamte Netzwerk gehört. Unterscheiden Sie daher Vorschlag, Aufnahme in den Quellcode, Veröffentlichung und tatsächlichen Einsatz. Zwischen diesen Schritten kann viel Arbeit und Zeit liegen. [15]

Ein Node lässt sich zunächst ohne eigene private Schlüssel betreiben. Pavel prüft Datei und Signaturen, lässt IBD fertiglaufen und kontrolliert, ob seine Wallet wirklich Daten seines Nodes nutzt. Danach beobachtet er Verbindungen, neue Blöcke und freien Speicher. Vor einem Upgrade liest er die Release Notes mit Änderungen und möglichen Umstiegsbedingungen; verwendet er eine Wallet, prüft er Sicherung und Wiederherstellung. Bei Problemen hilft die Diagnosedatei debug.log, die nicht unüberlegt veröffentlicht werden sollte. Pruning, Indizes und RPC müssen zum Einsatz passen, nicht zu einer blind kopierten Anleitung. Ein eigener Node soll ein verständliches Prüfwerkzeug sein. Für einen ersten kleinen Kauf ist er keine Pflicht, aber sinnvoll, wenn Sie selbst nachvollziehen möchten, warum Ihre Zahlungen als gültig gelten. [12] [14]