Bitcoin Core: Validation, Testkultur und drei parallele Release-Linien
Bitcoin Core-Integrations-/Staging-Baum. Entwicklungsprozess Der Master-Zweig wird regelmäßig erstellt (Anweisungen finden Sie in doc/build-*.md) und getestet, es kann jedoch nicht garantiert werden, dass er vollständig stabil ist.
Auf einen Blick
- Was ist das?
- Wie das Repository bitcoin/bitcoin aufgebaut ist: vollständige Blockvalidierung im P2P-Netzwerk, ctest und Python-Tests, CI auf drei Plattformen und die Versionslinien v29.4, v30.3 und v31.1, geprüft am README.
- Für wen ist es gedacht?
- Bitcoin Core passt für Nutzer, die Blöcke und Transaktionen selbst vollständig validieren wollen statt auf Fremdanbieter zu vertrauen, und für Entwickler, die an der Referenzimplementierung mitarbeiten. Es passt weniger, wer eine leichte Wallet-Lösung ohne eigenes Datenverzeichnis sucht.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Bitcoin Core: der Integrations- und Staging-Baum hinter bitcoincore.org
Das Repository bitcoin/bitcoin beschreibt sich als Bitcoin Core integration/staging tree, geschrieben in C++, lizenziert unter MIT, mit 90025 Sternen und 39354 Forks das größte Repository seiner Art im Bitcoin-Ökosystem. Die Software verbindet sich laut README mit dem Bitcoin-Peer-to-Peer-Netzwerk, um Blöcke und Transaktionen herunterzuladen und vollständig zu validieren.
Genau darin liegt die Funktion: Ein Bitcoin-Core-Knoten vertraut nicht den Angaben anderer Teilnehmer, sondern prüft jede Transaktion gegen die Regeln des Systems selbst. Eine Wallet und eine grafische Oberfläche sind enthalten, können beim Bau aber optional weggelassen werden. Wer keine eigene Binary bauen will, findet fertige Versionen unter bitcoincore.org/en/download, weiterführende Dokumentation liegt im doc-Ordner des Repository. Mit 713 offenen Issues und aktivem master-Branch ist das Projekt in Dauerbewegung.
Drei Release-Linien parallel: v29.4, v30.3 und v31.1 im Juli 2026
Die Release-Liste zeigt eine für Betriebsteams wichtige Eigenheit: Anfang Juli 2026 erschienen binnen drei Tagen Bitcoin Core 29.4, Bitcoin Core 31.1 und Bitcoin Core 30.3, also Punkte-Releases aus drei Major-Versionen gleichzeitig. Das Projekt pflegt demnach mehrere Versionslinien nebeneinander, vermutlich damit Betreiber mit Migrationen Zeit haben, das README sagt es nicht ausdrücklich.
Für die eigene Planung heißt das: Die Wahl der Version ist eine aktive Entscheidung. Wer einen lange laufenden Knoten betreibt, sollte prüfen, welche Linie seine Version noch bekommt, und die Release-Notes der jeweiligen Linie lesen, statt nur auf das höchste Tag zu schauen. Die Tags selbst sind unter github.com/bitcoin/bitcoin/tags zu finden, sie werden laut README regelmäßig aus Release-Branches erzeugt und markieren die offiziellen stabilen Versionen.
Vom master-Branch zu stabilen Tags: Entwicklungsprozess und Build-Doku
Der Entwicklungsprozess ist im README knapp dokumentiert: Der master-Branch wird regelmäßig gebaut und getestet, ist aber laut Text ausdrücklich nicht garantiert vollständig stabil. Bauanleitungen für verschiedene Plattformen liegen in Dateien mit dem Namensmuster doc/build-*.md, wer den Quellcode übersetzen will, startet dort.
Der Beitragsweg läuft über CONTRIBUTING.md, nützliche Hinweise für Entwickler stehen in doc/developer-notes.md. Eine Besonderheit ist das getrennte Repository github.com/bitcoin-core/gui, das ausschließlich für die Entwicklung der grafischen Oberfläche dient; sein master ist in allen Monotree-Repositories identisch, Release-Branches und Tags existieren dort nicht, und das README bittet ausdrücklich, dieses Repository nicht zu forken außer zu Entwicklungszwecken. Die GUI-Entwicklung ist damit bewusst vom Hauptbaum entkoppelt.
ctest und test_runner.py: die zwei Testebenen von Bitcoin Core
Die Teststruktur besteht aus zwei Ebenen. Unit-Tests liegen unter src/test, deren Beschreibung steht in src/test/README.md, ausgeführt werden sie mit ctest, sofern sie beim Erzeugen des Build-Systems nicht deaktiviert wurden. Die Regression- und Integrationstests sind in Python geschrieben, liegen im test-Ordner und laufen über build/test/functional/test_runner.py, sofern die Testabhängigkeiten installiert sind.
Zur Testkultur gehört eine offene Aussage im README: Testing und Code-Review sind der Engpass der Entwicklung, es kommen mehr Pull Requests herein, als kurzfristig geprüft werden können. Das Projekt bittet darum, geduldig zu sein und Pull Requests anderer mitzutesten. Dazu kommt ein Formulierungsstück, das den Rahmen setzt: Dies ist ein sicherheitskritisches Projekt, in dem jeder Fehler Menschen viel Geld kosten kann. Für die manuelle Qualitätssicherung gilt die Regel, dass Änderungen von jemand anderem als dem Autor getestet werden sollten, bei großen oder riskanten Änderungen gehört ein Testplan in die Pull-Request-Beschreibung.
CI auf Windows, Linux und macOS: Merge-Regeln für Pull Requests
Die Continuous-Integration-Systeme prüfen laut README jeden Pull Request auf Windows, Linux und macOS. Die Bedingung ist strikt: Die CI muss auf allen Commits bestehen, bevor ein Merge passiert, damit neue Pull Requests nicht durch unrelated CI-Ausfälle blockiert werden. Für Beitragende bedeutet das, dass Plattformfehler auf einem der drei Systeme den Merge stoppen, auch wenn die eigene Entwicklungsumgebung lokal grün war.
Unit-Tests für neuen Code sind stark erwünscht, das README fordert Entwickler ausdrücklich auf, Unit-Tests für alte Code nachzureichen. Diese Kombination aus dreiplattform-CI, Testpflicht für neuen Code und Fremd-Review ist der Hauptgrund, warum der master-Branch trotz hohen Änderungstempos als brauchbarer Integrationsstand gilt, die Stabilitätsgarantie bleibt trotzdem bewusst offen formuliert.
Übersetzungen über Transifex und die Sonderrolle des GUI-Repositorys
Übersetzungen laufen nicht über GitHub-Pull Requests, sondern über die Transifex-Seite des Projekts unter explore.transifex.com/bitcoin/bitcoin. Das README erklärt den Grund: Übersetzungen werden periodisch aus Transifex in das Git-Repository gezogen, ein GitHub-Pull Request würde beim nächsten Abzug automatisch überschrieben. Die Details beschreibt doc/translation_process.md.
Diese Regel ist ein praktisches Beispiel dafür, dass Beitragenswege je nach Beitragstyp unterschiedlich sind: Code über Pull Requests nach CONTRIBUTING.md, Tests über src/test und test/, Übersetzungen ausschließlich über Transifex. Wer zum ersten Mal beitragen will, sollte also vor dem ersten Pull Request prüfen, ob die geplante Änderung überhaupt in den GitHub-Workflow gehört, bei Übersetzungsdateien tut sie das nicht.
Redaktionelles Fazit
Bitcoin Core passt für Nutzer, die Blöcke und Transaktionen selbst vollständig validieren wollen statt auf Fremdanbieter zu vertrauen, und für Entwickler, die an der Referenzimplementierung mitarbeiten. Es passt weniger, wer eine leichte Wallet-Lösung ohne eigenes Datenverzeichnis sucht. Vor dem Einsatz sollte die passende Release-Linie gewählt werden, im Juli 2026 wurden v29.4, v30.3 und v31.1 parallel gepflegt, und die heruntergeladene Binary sollte von bitcoincore.org/en/download stammen, nicht aus fremden Quellen.
Community-Notizen