Bitcoin Core 32.1 am 27. Oktober 2026 veröffentlicht: Warum 32.0 zurückgezogen wurde, die drei offengelegten Fehler und der neue Gebührenschätzer

1. Was ist Bitcoin Core 32.1, und warum gibt es kein 32.0?

Bitcoin Core ist die Referenzimplementierung von Bitcoin, die Software, die Blöcke validiert, Transaktionen weiterleitet und hinter vielen Diensten die Wallet stellt. Etwa alle sechs Monate erscheint eine neue Major-Version, und die drei neuesten werden gepflegt. Version 32.1, veröffentlicht am 27. Oktober 2026, ist das erste öffentliche Release der 32.x-Linie, mit einem neuen Gebührenschätzer, höheren Standardwerten für Verbindungen, einem kleineren Transaktionsindex, PSBT Version 2 als Standard in den Wallet-RPCs und einem Bündel von Sicherheitskorrekturen. An den Konsensregeln ändert es nichts: Blöcke und Transaktionen, die vorher gültig waren, sind es auch danach.

32.0 existiert nur als Tag. Maintainer fanquake hat ihn am 21. Oktober gesetzt und am 26. Oktober im Issue zum Release-Zeitplan geschrieben, dass 32.0 wegen Problemen in letzter Minute weder angekündigt noch veröffentlicht werde und keine Binaries hochgeladen würden; 32.1 werde mit demselben Inhalt plus zusätzlichen Korrekturen folgen. Der Pull Request, der 32.1 finalisiert hat, am selben Nachmittag gemergt, portiert genau drei Änderungen von Antoine Poinsot zurück: Die Überwachung von Socket-Ausnahmen wird zwischen dem poll- und dem select-Backend vereinheitlicht, Peers, deren Sendepuffer sich nie leert, bekommen einen Timeout von 20 Minuten, und die Positionen in den Block- und Undo-Dateien werden 64 Bit breit. Das sind die Korrekturen für die drei zwei Tage später offengelegten Schwachstellen, beschrieben in Abschnitt 3. Mehr als das hat das Projekt zu den Gründen nicht gesagt.

2. Wann ist es erschienen? Die wichtigsten Termine

Die Termine stammen aus dem Issue zum Release-Zeitplan von Bitcoin Core, vom Download-Server von bitcoincore.org und aus den Offenlegungsbeiträgen. Stand 1. November 2026.

3. Welche Schwachstellen wurden behoben und offengelegt?

Drei, alle am 28. Oktober 2026 veröffentlicht und alle auf demselben Weg gefunden: durch einen automatisierten Scan des Codes mit einem großen Sprachmodell, den Elias Rohrer bei Spiral als Project Loupe betreibt, wobei Gregory Sanders jeden Fund geprüft und an das Sicherheitsteam von Bitcoin Core gemeldet hat. Zwei davon wurden von anderen Forschern unabhängig wiederentdeckt, bevor die Korrekturen erschienen. Die Richtlinie von Bitcoin Core sieht vor, Fehler, die es als leicht auffindbar einstuft, offenzulegen, sobald für jeden gepflegten Zweig ein korrigiertes Release existiert; deshalb erschienen die Beiträge einen Tag nach 32.1.

CVE-2026-117349, Schweregrad mittel: Ein Peer, der angibt, keine Pings nach BIP 31 zu unterstützen, wird nie dafür getrennt, dass er sie ignoriert, und liest er zusätzlich sehr langsam, reiht der Node Transaktionsankündigungen für ihn ohne Grenze in die Warteschlange ein. Der Beitrag beziffert das Wachstum auf bis zu etwa 2 MB pro Stunde bei einem eingehenden und 5 MB pro Stunde bei einem ausgehenden Peer; Nodes mit blocksonly sind deutlich weniger betroffen. Gemeldet am 15. September, behoben durch Pull Request #36667, der einen pausierten Peer trennt, dessen Sendepuffer sich nicht innerhalb von 20 Minuten geleert hat.

CVE-2026-117350, Schweregrad mittel, betrifft nur Windows, macOS und BSD: Der select-basierte Socket-Code prüfte auch dann auf Ausnahmezustände, wenn das Lesen wegen Backpressure pausiert war, ein Peer konnte also mit TCP-Urgent-Daten Lesevorgänge erzwingen, die das Speicherlimit pro Peer umgehen, bis dem Node der Speicher ausgeht. Linux nutzt poll und ist nicht betroffen. Gemeldet am 23. Oktober, drei Tage bevor die Korrekturen gemergt wurden, und behoben durch Pull Request #36665.

CVE-2026-117346, Schweregrad niedrig: Die Positionen in den Block- und Undo-Dateien waren 32 Bit breit, sobald eine Undo-Datei also 4 GiB überschritt, überschrieben neuere Daten ältere, und ein späterer Reorg, der diese Daten brauchte, hätte den Node heruntergefahren, bis ein Reindex auf einer korrigierten Version erfolgt. Unter Windows und auf 32-Bit-Systemen schlagen Schreibvorgänge jenseits von 2 GiB fehl. Der Beitrag nennt eine Ausnutzung auf 64-Bit-Systemen unpraktikabel: Ein Miner bräuchte mehrere tausend Blöcke mit Nicht-Standard-Transaktionen, etwa einen Monat an Blöcken, exakt platziert, dazu einen bestimmten Reorg über zwei Blöcke. Erstmals gemeldet am 8. Juli, behoben durch Pull Request #36669, der die Positionen als 64-Bit-Ganzzahlen speichert, ohne das Format auf der Festplatte zu ändern; 32-Bit-Systeme bleiben betroffen.

Die Release Notes von 32.1 selbst listen weitere Korrekturen, die keine CVEs sind: ein Wiederholungsversuch beim Private Broadcast, der die IP-Adresse des Absenders preisgeben konnte, weil er den Tor-Proxy umging, ein Weg zur Befehlsausführung über präparierte Wallet-Namen mit walletnotify auf Nicht-Windows-Systemen sowie Obergrenzen von 10.000 wartenden Private-Broadcast-Transaktionen und 1.000 Sendeversuchen je Transaktion. Die Notes sagen außerdem, dass das Projekt in zwei Wochen drei in 30.0 behobene Schwachstellen mit mittlerem und hohem Schweregrad offenlegen wird (und keine mit niedrigem Schweregrad in 32.1), ein weiterer Offenlegungsbeitrag steht also um den 10. November an.

4. Wie verändert der neue Gebührenschätzer die Gebühren, die du zahlst?

Wenn du eine Wallet oder einen Dienst nutzt, der einen Bitcoin-Core-Node über estimatesmartfee nach einer Gebühr fragt, ändert 32.1, was dabei herauskommt. Bisher nutzte Core nur seinen Block-Policy-Schätzer, der auf die Gebührensätze der Transaktionen zurückblickt, die innerhalb einer Zielzahl von Blöcken bestätigt wurden. Er ist konservativ und kommt nur langsam herunter: Nach einer Überlastungsspitze schlägt er noch eine Weile hohe Sätze vor, weil die Historie weiterhin hoch sagt. 32.1 ergänzt einen Mempool-Policy-Schätzer, der sich ansieht, was gerade wartet, und estimatesmartfee liefert den niedrigeren der beiden Werte. Der Mempool-Schätzer kann das Ergebnis nur senken, nie erhöhen, eine Core-basierte Wallet hört also früher auf, zu viel zu zahlen, sobald sich die Blöcke leeren, und verhält sich bei vollem Mempool wie bisher.

Dieselbe Idee steckt hinter den Sätzen, die die meisten Explorer anzeigen. Am 1. November 2026 setzt mempool.space, das allein aus dem Mempool schätzt, das Ziel von einer halben Stunde bei 1 sat/vB an, $0.11 für eine typische Überweisung bei einem BTC-Kurs von 77.731 $:

Bitcoin-Gebührensätze gerade jetzt (mempool.space)

Für Entwickler bekommt das RPC ein Options-Objekt: fee_rate_estimator akzeptiert auto (Standard, kombiniert), block_policy (das alte Verhalten) oder mempool_policy, unbekannte Werte werden abgelehnt, Verbosity 2 ergänzt mempool_health_statistics, und im Modus auto nennt die Antwort den verwendeten Schätzer. Die Daten des Block-Policy-Schätzers wandern nach fees/block_policy_estimates.dat und werden beim ersten Start migriert. Die Coin-Auswahl der Wallet selbst nutzt die kombinierte Schätzung. Was sich nicht ändert: Die Gebühr bleibt deine Entscheidung, Replace-by-Fee und Child-Pays-for-Parent retten weiterhin eine Transaktion, die zu wenig gezahlt hat, und die sat/vB-Stufen in unserem Gebühren-Leitfaden aktualisieren sich jede Minute aus dem Mempool.

5. Was ändert sich für Node-Betreiber?

Aktualisieren, und prüfen, auf welchem Zweig du bist. 29.x hat am 27. Oktober 2026 das End of Life erreicht, und 29.5 vom 28. Oktober ist sein letztes Release, ein Node auf 29.x bekommt also keine weiteren Korrekturen; 30.x bleibt gepflegt, bis 33.0 erscheint, 31.x bis 34.0 und 32.x bis 35.0. Das Upgrade von einer End-of-Life-Version direkt auf 32.1 wird unterstützt, die Migration des Datenverzeichnisses kann aber Zeit brauchen. Unterstützte Plattformen sind Linux ab Kernel 3.17, macOS ab 14 und Windows 10 ab Version 1903.

Zwei Standardwerte verändern deinen Fußabdruck. Der Standard für maxconnections steigt von 125 auf 200, und eine neue Option inboundrelaypercent (Standard 50) begrenzt den Anteil der eingehenden Slots, die an Peers gehen, die Transaktionen weiterleiten; wer das alte Verhalten behalten will, startet mit maxconnections=125 und inboundrelaypercent=100. Die ausgehende Weiterleitung von Transaktionen ist jetzt ratenbegrenzt, mit einem globalen Rückstand (txsendrate, Standard 14 Transaktionen pro Sekunde, das 2,5-Fache davon für ausgehende Peers, plus eine Bandbreitenobergrenze von 12 MB pro 10 Minuten). Automatisch erstellte Tor Hidden Services bekommen Proof-of-Work-Schutz, wenn der Tor-Daemon ihn unterstützt. Der RPC-Server nutzt kein libevent mehr, und eine neue Option rpcmaxconnections (Standard 16) begrenzt die Zahl gleichzeitiger HTTP-Clients.

Zwei Optionen sparen Platz und Zeit. Der Transaktionsindex speichert weniger Daten: Ein neu aufgebauter txindex braucht weniger als die Hälfte des Platzes, die Ersparnis bekommst du aber nur, wenn du indexes/txindex im Datenverzeichnis löschst und neu startest, was Stunden dauern kann; der txospenderindex schrumpft auf dieselbe Weise. Die Blockvalidierung lädt vorherige Outputs parallel vor, mit prevoutfetchthreads, Standard 8, maximal 16, 0 zum Abschalten. Die alten I2P-ElGamal-Sitzungen werden bis v34 entfernt, und die CJDNS-Unterstützung steht auf dem Prüfstand, wer auf eines von beiden angewiesen ist, sollte also die nächsten Release Notes verfolgen.

6. Was ändert sich für Entwickler und Wallets?

Der Breaking Change ist PSBT Version 2. createpsbt, walletcreatefundedpsbt, converttopsbt und psbtbumpfee erzeugen jetzt standardmäßig PSBTs der Version 2; ein neues Argument psbt_version wählt Version 0 für Tooling, das v2 noch nicht lesen kann. Wenn ein Signiergerät, ein Koordinator oder ein Skript in deinem Ablauf nicht mit PSBTv2 getestet ist, übergib das Argument, bevor du den Node aktualisierst, mit dem es spricht.

Mehrere Felder und Optionen sind als veraltet markiert: vsize in den Mempool-RPCs und in getrawtransaction (nutze vsize_adjusted oder vsize_bip141 für die rohe Größe nach BIP 141), die Startoption walletrbf und der Schlüssel bip125-replaceable (Nodes leiten seit Core 28 Ersetzungen jeder Transaktion weiter) sowie das RPC removeprunedfunds, das jetzt deprecatedrpc=removeprunedfunds braucht. Wallet-Namen mit Punkt-Pfadelementen oder eine Wallet, die nur nach einem Schrägstrich benannt ist, werden abgelehnt.

Neu in der RPC-Schnittstelle: exportwatchonlywallet, addhdkey und derivehdkey; send und sendall gelten nicht mehr als experimentell; getblockchaininfo meldet den Fortschritt der assumeutxo-Hintergrundvalidierung; getbalances ergänzt einen Saldo ohne Mempool (nonmempool); getnetworkinfo meldet die asmap-Version; exportasmap und getopenrpcinfo; ein Befehl bitcoin-util getchainparams. Der eigene HTTP-Server ist strenger bei Headern, prüfe also jeden Client, der ungewöhnliche sendet. Nichts davon berührt, wie eine Transaktion gebaut oder gesendet wird, SDKs, die über Standard-RPC mit einem Node sprechen, darunter ChainGate, funktionieren also weiter.

7. Müssen Bitcoin-Nutzer etwas tun?

Nein. 32.1 ändert keine Konsensregel, es gibt also keinen Fork, keinen neuen Coin und nichts zu migrieren; deine Schlüssel, Adressen und Guthaben bleiben dieselben. Wenn du eine Light Wallet nutzt oder deine Coins auf einer Börse liegen, findet das Upgrade auf den Rechnern anderer Leute statt.

Was du bemerken könntest: Eine Wallet, die mit einem Core-Node verbunden ist, schlägt in den Stunden nach einer Stoßzeit niedrigere Gebühren vor, weil der Schätzer jetzt den Mempool liest. Wenn du einen eigenen Node betreibst, aktualisiere; wenn du auf 29.x bist, läufst du seit dem 27. Oktober auf einem Zweig ohne Pflege. Wer dich auffordert, deine Bitcoin wegen eines Core-Releases zu bewegen oder zu "updaten", will dich betrügen.

8. Was ist bestätigt und was ist noch offen?

9. Was kommt als Nächstes?

Der nächste datierte Punkt ist die Offenlegung der drei in 30.0 behobenen Schwachstellen, die die Release Notes zwei Wochen nach dem Release versprechen, also um den 10. November 2026. Wir tragen sie hier nach, zusammen mit jedem 32.x-Wartungs-Release. Das Änderungsprotokoll unten hält fest, was sich wann geändert hat.

Bis dahin zeigt der Leitfaden zu Bitcoin-Gebühren die Live-Stufen in sat/vB, denen der neue Schätzer gerade hinterherkommt, der Leitfaden zum Transaktions-Hash erklärt, wie du eine wartende Transaktion verfolgst, und der Beitrag zur Schließung von Binance Pool behandelt, was mit hängenden Transaktionen passiert, sobald dieser Accelerator am 10. November schließt.

Änderungen an diesem Artikel

• 31. Oktober 2026: Erstveröffentlichung. Termine aus dem Issue zum Release-Zeitplan von Bitcoin Core, vom Download-Server von bitcoincore.org und von den Release-Seiten; Details zu den Schwachstellen aus den drei Offenlegungsbeiträgen vom 28. Oktober; Inhalt des Releases aus den Release Notes zu 32.1 und von der Lifecycle-Seite.

Häufig gestellte Fragen