Bitcoin Core und andere Implementierungen

Neugier

1. Wer entscheidet, was ein Block ist, wenn zwei Programmcodes sich uneinig sind?
2. Warum kann ein kleiner Datenbankfehler die Chain in zwei Hälften spalten?
3. Was passiert mit dem Netzwerk, wenn die beliebteste Implementierung einfach nicht mehr gewartet wird?

Erkunden

1. Bitcoin begann als einzelner C++-Client, geschrieben von Satoshi Nakamoto. 2011 wurde die Benutzeroberfläche mit den Qt-Bibliotheken neu geschrieben, und die Software wurde als Bitcoin-Qt bekannt. 2014 hatte Version 0.9 den Zusatz ganz abgelegt und hieß nun Bitcoin Core. Die Namensänderung spiegelte einen Identitätswandel wider: Es war nicht mehr nur Satoshis Werkzeug, sondern die maßgebliche Referenzimplementierung der Netzwerkregeln.
2. Die Leitung der Codebasis ging von Gavin Andresen, der sie von 2010 bis zu seinem Rückzug 2014 innehatte, auf Wladimir van der Laan über. Heute führt eine kleine Gruppe von Maintainern Änderungen nach gründlichem Peer Review zusammen. Das Versionsschema sprang 2021 von 0.21 auf 22.0, ein Zeichen der Reife. Major Releases erscheinen etwa zweimal pro Jahr, und jedes wird vor der Veröffentlichung umfassend getestet.
3. Konsens ist nicht nur eine Frage der Logik, sondern eines byte-genau identischen Verhaltens auf Zehntausenden von Nodes. Im März 2013 führte Version 0.8 LevelDB als Speicher-Engine ein. Ein Block, den die neue Software akzeptierte, wurde von älteren Versionen mit Berkeley DB wegen eines Fehlers beim Lock-Limit abgelehnt. Die Chain blieb gespalten, bis die Miner auf die ältere Version zurückgingen – ein Beleg dafür, dass ein verborgener Verhaltensunterschied, nicht einmal im Konsenscode selbst, das Netzwerk spalten kann.
4. Alternative Implementierungen gibt es, damit keine einzelne Codebasis zum Single Point of Failure oder zum Ziel einer Vereinnahmung wird. btcd ist in Go geschrieben, bcoin in JavaScript und libbitcoin in C++. Bitcoin Knots, betreut von Luke Dashjr, ist ein Patch-Set auf Basis von Core mit anderen Standardeinstellungen, insbesondere einer strengeren Filterung datentragender Transaktionen. Floresta nutzt die Datenstruktur Utreexo für eine effiziente Verifizierung. Diese Projekte wirken als Korrektiv für den Entwicklungsprozess von Core.
5. Das Risiko, den Konsens neu zu implementieren, ist hoch, denn ein Fehler, der ungültige Blöcke akzeptiert, kann zu finanziellen Verlusten oder Chain-Splits führen. Um dem entgegenzuwirken, soll libbitcoinkernel die zentrale Konsenslogik in einer wiederverwendbaren Bibliothek isolieren. So kann andere Software Transaktionen verifizieren, ohne die gesamte Node-Codebasis zu duplizieren, und die Regeln bleiben einheitlich, auch wenn sich die umgebende Infrastruktur ändert.
6. Führen Sie auf einem Node 'bitcoin-cli getnetworkinfo' aus, um seine eigene Version zu sehen, und 'getpeerinfo', um zu sehen, welche Software jeder Peer meldet (seinen 'subver'-String). Das Netzwerk bleibt trotz unterschiedlicher Software-Stacks interoperabel, doch die Dominanz von Bitcoin Core bedeutet, dass es faktisch das Tempo für Protokoll-Upgrades vorgibt. Nodes, die nicht aktualisieren, folgen der Chain bei Soft Forks weiterhin, doch ein Node, dessen Konsensverhalten abweicht, kann abgespalten werden.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• Bitcoin Core release notes for version 0.9.0 (2014)
• BIP50: March 2013 Chain Fork Post-Mortem
• Bitcoin Core release notes and documentation (bitcoincore.org)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10