Bitcoin Core 32.0 kommt am 10. Oktober: So prüfst du, ob dein Knoten aus der Wartung fällt

Seit dem 14. September 2026 liegt der erste Release-Kandidat von Bitcoin Core 32.0 vor. Für dich als Betreiber eines eigenen Knotens heißt das zweierlei: Der Funktionsumfang der kommenden Hauptversion steht fest, und mit ihrem Erscheinen fällt die 29er-Serie aus dem Wartungsfenster des Projekts. Wer heute noch auf 29.x läuft, bekommt nach dem geplanten Termin am 10. Oktober keine Sicherheitskorrekturen mehr. Die Prüfung dauert zwei Minuten, das Update kostet je nach Aufbau eine halbe Stunde.

Eine eigene Auszählung der weltweit erreichbaren Knoten, die wir für diesen Artikel am Morgen des 15. September durchgeführt haben, zeigt, wie groß die betroffene Gruppe ist: Rund sechs von zehn erreichbaren Bitcoin-Knoten laufen auf einer Version, die nach dem Erscheinen von 32.0 keine gepflegte Version mehr ist. Die Zahlen und die Methode stehen weiter unten.

Bitcoin Core 32.0: Was am 14. September passiert ist

Bitcoin Core ist die Referenzsoftware des Bitcoin-Netzwerks. Sie prüft Blöcke und Transaktionen gegen die Konsensregeln, hält eine eigene Kopie der Blockchain vor und ist damit die Grundlage für jeden, der seinen Zahlungsverkehr nicht einer fremden Infrastruktur überlässt. Das Projekt veröffentlicht nach eigener Vorgabe etwa alle sechs Monate eine Hauptversion.

Am 14. September 2026 ist im Quellcodeverzeichnis des Projekts der Tag v32.0rc1 aufgetaucht, also der erste Release-Kandidat der kommenden Hauptversion. Das Branchenmedium TFTC nennt dafür 12:58 UTC und gibt als geplanten Termin für den finalen Tag den 10. Oktober 2026 an. Damit liegt zwischen Kandidat und Freigabe ein Testfenster von rund vier Wochen. Zum Vergleich: Die zuletzt freigegebene Hauptversion 31.0 stammt laut dem Lebenszyklus-Plan des Projekts vom 19. April 2026, die dazugehörige Wartungsfassung 31.1 trägt im Download-Verzeichnis den 7. Juli 2026.

Ein Release-Kandidat ist kein Vorabtest im Sinne einer Beta. Der Code gilt als funktional vollständig. Was jetzt noch hineinkommt, sind ausschließlich Korrekturen für Fehler, die während des Testfensters auffallen. Für dich als Betreiber bedeutet das: Der Inhalt der kommenden Version ist bekannt, und du kannst deine Konfiguration schon jetzt dagegen prüfen, statt am Tag der Freigabe überrascht zu werden.

Release-Kandidat, Feature-Freeze, Wartungsfenster: drei Begriffe für diesen Artikel

Release-Kandidat

Ein Release-Kandidat ist eine Fassung, die das Projekt für veröffentlichungsreif hält und vor der endgültigen Freigabe breit testen lässt. Sie trägt den Zusatz rc1, rc2 und so weiter und wird zurückgezogen oder ersetzt, wenn ein schwerer Fehler auffällt.

Feature-Freeze

Ein Feature-Freeze ist der Zeitpunkt, ab dem keine neuen Funktionen mehr in eine Version aufgenommen werden. Er liegt vor dem ersten Release-Kandidaten und ist der Grund, warum sich der Funktionsumfang von 32.0 jetzt schon beschreiben lässt.

Wartungsfenster

Das Wartungsfenster ist der Zeitraum, in dem eine Hauptversion noch Fehler- und Sicherheitskorrekturen bekommt. Bitcoin Core pflegt nach dem eigenen Lebenszyklus-Plan immer die drei jüngsten Hauptversionen. Sobald eine neue Hauptversion erscheint, rutscht die älteste dieser drei heraus und gilt als End of Life. Versionen im End-of-Life-Zustand erhalten in aller Regel auch keine Sicherheitskorrekturen mehr.

Eigene Auswertung: 60 Prozent der erreichbaren Knoten verlieren mit 32.0 die Pflege

Diese Auswertung hat cryptoticker.io am 15. September 2026 selbst erhoben. Methode in einem Satz: Wir haben um 06:35 UTC den öffentlichen Schnappschuss des Knotenzählers btcnodes.io (vormals bitnodes.io) abgerufen und die von jedem Knoten selbst gemeldete Versionskennung nach Hauptversionen ausgezählt.

Geprüft wurden 26.516 Knoten aus diesem Schnappschuss. Davon tragen 25.902 eine Kennung der üblichen Form mit Versionsnummer; die übrigen 614 melden eine andere Software, allein 556 davon eine Bibliotheksimplementierung ohne Versionsbezug zu Bitcoin Core. Die Auszählung bezieht sich auf diese 25.902 Knoten.

• 29.x: 8.629 Knoten (33,31 Prozent) – genau die Serie, die mit dem Erscheinen von 32.0 aus der Pflege fällt.
• 28.x und älter: 7.017 Knoten (27,09 Prozent) – bereits heute ohne Wartung. Die 28er-Serie ist seit dem 19. April 2026 End of Life.
• 30.x: 1.732 Knoten (6,69 Prozent) und 31.x: 8.512 Knoten (32,86 Prozent) – die beiden Serien, die nach der Freigabe neben 32.x weitergepflegt werden.
• 32.x: 12 Knoten (0,05 Prozent) – vermutlich Testsysteme, die den Kandidaten bereits fahren.

Rechnet man die 29er-Serie und alles Ältere zusammen, sind das 15.646 Knoten oder 60,40 Prozent. Diese Mehrheit steht am Tag nach der Freigabe ohne gepflegte Software da. Nebenbefund derselben Auszählung: 4.459 Knoten (17,2 Prozent) melden zusätzlich die Kennung der abweichenden Implementierung Bitcoin Knots, die einen eigenen Veröffentlichungsrhythmus hat und von diesem Wartungsplan nicht berührt wird.

Was diese Erhebung nicht kann, gehört dazu: Der Schnappschuss enthält kein Länderfeld, eine gesonderte Zahl für Deutschland lässt sich daraus also nicht ableiten. Die Versionskennung ist eine Selbstauskunft und technisch fälschbar. Und gezählt werden ausschließlich Knoten, die von außen erreichbar sind. Wer seinen Knoten hinter einer Firewall betreibt oder ihn ausschließlich über Tor erreichbar macht, taucht in dieser Statistik nicht auf. Die tatsächliche Zahl veralteter Installationen dürfte also eher höher liegen als hier ausgewiesen.

Wartungsfenster von Bitcoin Core: Welche Version wann aus der Pflege fällt

Der Lebenszyklus-Plan des Projekts ist eine öffentliche Tabelle und lässt sich Zeile für Zeile nachlesen. Die für dich wichtigen Einträge:

• 29.x, erschienen am 14. April 2025: End of Life mit dem Erscheinen von 32.0, also nach heutigem Stand am 10. Oktober 2026.
• 30.x, erschienen am 10. Oktober 2025: End of Life erst mit 33.0.
• 31.x, erschienen am 19. April 2026: End of Life erst mit 34.0.
• 28.x: seit dem 19. April 2026 End of Life.

Das Projekt empfiehlt ausdrücklich, die jeweils jüngste Wartungsfassung der höchsten Hauptversion zu fahren, auf die man wechseln kann. Es gibt dabei eine Besonderheit, die für einen ruhigen Upgrade-Pfad spricht: Vorschläge für Änderungen an den Konsensregeln liefert das Projekt zuerst in Wartungsversionen aus, nicht in Hauptversionen. Wer konservativ aktualisiert, bleibt dadurch trotzdem anschlussfähig, solange die eigene Hauptversion gepflegt wird. Genau diese Anschlussfähigkeit endet für die 29er-Serie im Oktober.

Core-Version ablesen: So findest du heraus, worauf dein Knoten läuft

Bevor du irgendetwas herunterlädst, stellst du fest, wo du stehst. Drei Wege, je nach Aufbau.

Kommandozeile

Auf einem Server oder Einplatinenrechner liefert bitcoind --version die Versionsnummer direkt in der ersten Zeile. Bei laufendem Dienst geht es auch über bitcoin-cli --version oder, wenn du ohnehin gerade mit dem Knoten sprichst, über den Aufruf bitcoin-cli getnetworkinfo; dort steht die Kennung im Feld subversion, also in derselben Form, die auch unsere Auszählung oben verwendet hat.

Grafische Oberfläche

In der Desktop-Anwendung findest du die Versionsnummer über den Menüpunkt Hilfe und dort im Fenster mit den Informationen zur Anwendung. Sie steht ebenfalls im Fenster für Debug-Informationen, das die Anwendung unter dem Menüpunkt Fenster anbietet.

Fertiges Knoten-Paket

Wer eine Fertiglösung betreibt, also ein vorkonfiguriertes Betriebssystem für den heimischen Knoten, liest die Core-Version in der Regel in der Detailansicht der jeweiligen Anwendung ab. Wichtig ist hier die Version von Bitcoin Core selbst, nicht die Versionsnummer der Oberfläche darum herum. Beide Zahlen unterscheiden sich fast immer, und nur die erste entscheidet über die Wartung.

Notiere dir die Zahl. Steht dort eine 29 oder etwas Kleineres, hast du eine Aufgabe für die nächsten Wochen. Steht dort 30 oder 31, bist du vorerst auf der sicheren Seite und kannst das Update in Ruhe planen.

Was sich in Bitcoin Core 32.0 ändert: Gebührenschätzung, Index, Schnittstelle

Der Entwurf der Veröffentlichungsnotizen für 32.0 liegt im Entwicklungs-Wiki des Projekts. Er ist ausdrücklich ein Entwurf und kann sich bis zum finalen Tag noch ändern; die folgenden Punkte sind deshalb als Richtung zu lesen, nicht als endgültiger Wortlaut.

Auffällig ist der Schwerpunkt auf Betrieb statt auf sichtbaren Funktionen. Die Gebührenschätzung kombiniert künftig den blockbasierten Schätzer mit dem Schätzer aus dem Mempool und fällt dadurch vorsichtiger aus. Der Transaktionsindex belegt laut Entwurf weniger als die Hälfte des bisherigen Plattenplatzes, allerdings nur nach einem Neuaufbau des Index. Für die Blockvalidierung kommt eine parallele Vorabholung der Eingangsdaten mit einer eigenen Einstellung für die Zahl der Arbeitsfäden hinzu, voreingestellt auf acht und begrenzt auf sechzehn.

Bei der Netzwerkschicht steht eine globale statt einer verbindungsbezogenen Begrenzung der Transaktionsweiterleitung im Entwurf, dazu ein Nachweis-Schutz für Tor-Dienste, wo die Gegenstelle das unterstützt. Die veraltete Verschlüsselung des I2P-Netzwerks läuft aus; wer seinen Knoten darüber betreibt, sollte den Wechsel vor Version 34 einplanen. Die Schnittstelle bekommt neue Aufrufe für den Umgang mit Schlüsseln und für den Export einer reinen Beobachtungs-Wallet, und der eingebaute HTTP-Server wurde neu geschrieben, samt einer neuen Obergrenze für gleichzeitige Verbindungen.

Nichts davon zwingt dich zu einer Handlung am Tag der Freigabe. Zwei Punkte solltest du dir trotzdem vormerken: den Neuaufbau des Index, wenn dir der Plattenplatz knapp wird, und die entfernten Einstellungen, um die es im nächsten Abschnitt geht.

Entfernte Optionen in der bitcoin.conf: Warum dein Knoten nach dem Update warnt

Der häufigste Ärger nach einem Hauptversionssprung kommt nicht aus dem Programm, sondern aus der eigenen Konfigurationsdatei. In 32.0 fallen laut Entwurf mehrere Einstellungen weg, die über Jahre in Anleitungen standen. Dazu gehören eine Einstellung zur vollständigen Ersetzbarkeit von Transaktionen im Mempool und eine ältere Netzwerkoption. Außerdem verschwinden zwei Schlüssel aus den Antworten der Mempool-Aufrufe, sofern du sie nicht ausdrücklich über die Einstellung für veraltete Schnittstellen wieder einschaltest.

Praktisch heißt das: Öffne deine bitcoin.conf, bevor du aktualisierst, und gleiche jede Zeile gegen die Veröffentlichungsnotizen ab. Ein Knoten, der wegen einer unbekannten Einstellung nicht startet oder mit Warnungen hochfährt, ist eine unnötige Nachtschicht. Wer eigene Skripte oder eine Buchhaltungssoftware an die Schnittstelle gehängt hat, prüft zusätzlich, ob dort einer der entfallenden Schlüssel ausgelesen wird.

Release-Kandidat testen, ohne den Produktivknoten zu riskieren

Vier Wochen Testfenster sind eine Einladung, und sie gilt auch für Betreiber ohne Entwicklerhintergrund. Je mehr unterschiedliche Aufbauten den Kandidaten fahren, desto eher fallen Fehler auf, bevor sie in der freigegebenen Fassung landen. Drei Regeln machen das Testen ungefährlich.

Erstens gehört ein Release-Kandidat nicht auf den Knoten, an dem deine Wallet hängt. Ein getrenntes Gerät, eine virtuelle Maschine oder der Testbetrieb im Testnetz reichen völlig. Zweitens prüfst du vor dem Start die Signatur der heruntergeladenen Dateien gegen die veröffentlichten Prüfsummen; das ist bei einer Vorabfassung genauso Pflicht wie bei einer regulären Freigabe. Drittens meldest du auffälliges Verhalten, solange das Fenster offen ist. Nach dem finalen Tag ist der Weg für Korrekturen deutlich länger.

Wer sichergehen will, legt vor jedem Versionssprung eine Sicherung der Wallet-Datei und der Konfigurationsdatei an und bewahrt sie getrennt vom Knoten auf. Das gilt für den Kandidaten wie für die spätere Freigabe. Wie streng dieselbe Disziplin bei Hardware-Geräten greift, hat sich in diesem Jahr am Fall eines Herstellers gezeigt, dessen Firmware-Fehler eine ganze Gerätegeneration betraf.

Kein eigener Knoten? Was das Update über deine Verwahrung aussagt

Der größere Teil der Leserschaft betreibt keinen eigenen Knoten, und das ist eine legitime Entscheidung. Trotzdem hat dieser Release eine Aussage für dich. Wer seine Bestände bei einer Börse oder einem Broker liegen lässt, verlässt sich darauf, dass dort jemand dieses Wartungsfenster im Blick hat. Wer selbst verwahrt, aber über eine Wallet-Anwendung auf einen fremden Server zugreift, verlässt sich auf denselben unbekannten Dritten, nur eine Ebene tiefer.

Der praktische Zwischenweg für die meisten ist die Trennung von Schlüsseln und Software: Die Schlüssel liegen auf einem Gerät, das nie am Netz hängt, die Software bleibt austauschbar. Welche Geräte dafür infrage kommen und worin sie sich unterscheiden, steht in unserem Vergleich der Hardware-Wallets. Der eigene Knoten kommt dann als zweiter Schritt dazu, und die Versionsfrage aus diesem Artikel wird ab da auch deine.

Dass Wartung kein Randthema ist, zeigen zwei Fälle aus den vergangenen Wochen: eine Schwachstelle in einer Lightning-Implementierung und eine kritische Lücke in einer verbreiteten Wallet-Oberfläche, bei der nur die Erreichbarkeit aus dem Internet über das Risiko entschied. In beiden Fällen war die Abhilfe ein Update, das bereitlag.

Was der Release nicht ist: keine Konsensänderung und kein Kursereignis

Eine Einordnung gegen naheliegende Fehlschlüsse. Bitcoin Core 32.0 ändert nach dem vorliegenden Entwurf keine Konsensregeln. Es gibt keine Abstimmung, keine Frist zur Signalisierung und keinen Zeitpunkt, zu dem ein nicht aktualisierter Knoten aus dem Netzwerk fällt. Ein Knoten mit Version 29 validiert nach dem 10. Oktober weiter korrekt. Was ihm fehlt, sind Korrekturen für Fehler, die danach gefunden werden.

Ebenso wenig ist ein Release ein Kursereignis. Wer eine Verbindung zwischen Versionsnummern und Preisbewegungen herstellt, behauptet etwas, das sich nicht belegen lässt. Die Relevanz dieses Termins liegt allein im Betrieb: in der Frage, ob die Software, die deine Zahlungen prüft, noch gepflegt wird.

Bleibt die Frage nach dem richtigen Zeitpunkt. Ein Sprung auf 32.0 am Tag der Freigabe ist für einen privaten Knoten kein Fehler, aber auch kein Muss. Wer 30.x oder 31.x fährt, hat Monate Zeit. Wer auf 29.x oder darunter steht, sollte den Wechsel im Oktober einplanen, und zwar auf die jüngste Wartungsfassung der höchsten Hauptversion, die der eigene Aufbau hergibt. Für Aufbauten, bei denen ein Vollknoten zu viel Plattenplatz verlangt, bleibt die abgeschnittene Betriebsart eine Option; die Validierungsarbeit erledigt der Knoten dabei unverändert.

Bitcoin Core 32 prüfen: Was du daraus mitnimmst

1. Version ablesen und notieren. Über bitcoind --version, über das Informationsfenster der Desktop-Anwendung oder in der Detailansicht deiner Fertiglösung. Steht dort 29 oder weniger, setzt du dir einen Termin im Oktober. Wer noch gar nicht selbst verwahrt, klärt zuerst die Schlüsselfrage und sieht sich dafür den Hardware-Wallet-Vergleich an.
2. Konfigurationsdatei und Sicherung vorbereiten. Jede Zeile deiner bitcoin.conf gegen die Veröffentlichungsnotizen abgleichen, Wallet-Datei und Konfiguration getrennt sichern. Wer seine Schlüssel in einer Anwendung auf dem Rechner hält, prüft parallel deren Update-Stand über unseren Vergleich der Software-Wallets.
3. Testen auf getrenntem Gerät, dann in Ruhe umsteigen. Den Kandidaten niemals auf dem Knoten fahren, an dem deine Wallet hängt. Und falls du feststellst, dass du gar keinen eigenen Knoten betreiben willst: Dann ist die Wahl des verwahrenden Anbieters die Entscheidung, die an dieser Stelle zählt, und dafür lohnt der Blick in den Börsenvergleich.

Die Belege zu diesem Artikel: der Lebenszyklus-Plan von Bitcoin Core mit der Wartungstabelle und die Tag-Liste des Quellcodeverzeichnisses, in der der Kandidat v32.0rc1 mit Datum steht.

(Stand: 15. September 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)