Die Referenzimplementierung von Bitcoin. Ihre Website veröffentlicht Ankündigungen neuer Versionen, Sicherheitshinweise und Stellungnahmen des Projekts.
Präparierte, nicht standardkonforme Transaktionen konnten einen Bitcoin-Core-Knoten jeweils einige Sekunden beschäftigen, ohne dass der Absender getrennt wurde; so ließ sich die Verbreitung von Blöcken verzögern. Die als niedrig eingestufte Lücke CVE-2025-46598 meldete Antoine Poinsot, v30.0 entschärft sie durch eine kürzere Validierungszeit im schlimmsten Fall.
Blöcke über 1 GB konnten auf 32-Bit-Knoten von Bitcoin Core eine Größenprüfung überlaufen lassen und beim Schreiben auf die Platte einen Absturz auslösen. Das klappt allerdings nur als Compact Block und nur bei einem Opfer, das -maxmempool über 3 GB betreibt und 1 GB Transaktionen im Mempool hält. Entdeckt hat CVE-2025-46597 Pieter Wuille, die Einstufung lautet niedrig; eine Obergrenze für -maxmempool auf 32-Bit-Systemen schloss die Lücke in 29.1 und 30.0.
Niedrigere Mindestgebühren gelten ab Werk in Bitcoin Core 28.3: -blockmintxfee sinkt auf 1 Satoshi pro kvB, -minrelaytxfee und -incrementalrelayfee auf 100 Satoshi pro kvB. Die Gebührensätze der Wallet bleiben unverändert, günstigere Transaktionen verbreiten sich unter Umständen erst, wenn die neuen Standardwerte im Netz angekommen sind. Whitelist-Berechtigungen gelten zudem nicht mehr für eingehende Onion-Verbindungen (#33395).
Zwei P2P-Fixes für FillBlock bringt Bitcoin Core 29.2: eine Prüfung auf Witness-Mutationen (#32646) und eine Prüfung auf leere Header vor dem Aufruf (#33296). Bei einem Reorg werden TRUC-Prüfungen nicht mehr durchgesetzt (#33504), getblock und getblockheader liefern das Target der Chain-Spitze nicht mehr zurück (#33446).
Die OP_RETURN-Grenze fällt in Bitcoin Core 30.0 praktisch weg: -datacarriersize steht standardmäßig auf 100.000, und eine Transaktion darf mehrere Daten-Outputs tragen; -datacarriersize=83 stellt die alte Obergrenze wieder her. Die Standard-Relay-Gebühr sinkt auf 0,1 Satoshi pro vB, Legacy-Signaturoperationen sind auf 2500 je Standardtransaktion begrenzt, und ein neuer Befehl bitcoin bündelt die vorhandenen Programme.
Unbedingtes Logging auf die Platte drosselt Bitcoin Core 29.1 auf 1 MiB pro Stunde je Quellcodestelle (#32604), Standardtransaktionen dürfen höchstens 2500 potenziell ausgeführte Legacy-Signaturoperationen enthalten. Die Standard-Relay-Gebühr fällt auf 100 Satoshi pro kvB, 32-Bit-Builds deckeln -maxmempool bei 500 MB und -dbcache bei 1 GiB.
Gut die Hälfte der Änderungen in Bitcoin Core 28.2 betrifft den Build. Guix notarisiert jetzt das macOS-App-Bundle und signiert alle Binaries für macOS und Windows (#31407), depends erhält Kompilier-Fixes für libevent unter NetBSD (#31500) und freetype unter cmake (#32693).
In einem Brief erklären 31 Contributors von Bitcoin Core, Knotensoftware solle das Weiterleiten von Transaktionen nicht verweigern, wenn dauerhafte wirtschaftliche Nachfrage besteht und sie zuverlässig in Blöcken landen, denn Nutzer und Miner könnten solche Filter umgehen. Das sei keine Befürwortung nichtfinanzieller Datennutzung, betonen sie, und allein die Nutzer entschieden, welche Software und Richtlinien sie einsetzen.
Jahrelanger Dauerbeschuss mit addr-Nachrichten konnte die 32-Bit-Kennung im Adressmanager von Bitcoin Core überlaufen lassen und den Knoten zum Absturz bringen; das ist der Rest eines Angriffs, den schon das Rate Limiting in v22.0 entschärft hatte. Version 29.0 wechselt auf eine 64-Bit-Kennung und schließt damit CVE-2024-52919, Einstufung niedrig. Entdeckt hat den Fehler Eugene Siegel, die Änderung stammt von Martin Zumsande.
UPnP fliegt aus Bitcoin Core 29.0 raus; -natpmp setzt statt auf libnatpmp nun auf eine eingebaute Implementierung von PCP und NAT-PMP. Neu ist die Policy Ephemeral Dust, ein Fix für doppelt reserviertes Blockgewicht bringt -blockreservedweight, und Knoten fragen jeden Peer, der eine Orphan-Transaktion angekündigt hat, nach deren fehlenden Eltern. Für die Versionen 26.x und älter endet die Wartung.
Ist -port gesetzt, leitet Bitcoin Core 28.1 den Standard-Onion-Port daraus ab, nämlich als Port plus eins, statt ihn im Mainnet fest auf 8334 zu legen. Mehrere lokale Knoten laufen so wieder ohne Kollision beim Start nebeneinander. Manuelle HiddenServicePort-Zeilen in der torrc müssen womöglich angepasst werden. In DecodeExtKey werden zudem geheime Daten gelöscht (#31166).
Kündigte ein Peer einen Block an und stellte sich dann tot, konnte ein Bitcoin-Core-Knoten bis zu 10 Minuten warten, bevor er es anderswo versuchte, und Angreifer konnten das wiederholen. Die als mittelschwer eingestufte Lücke CVE-2024-52922, von Greg Sanders gemeldet und behoben, ist in v25.1 und v26.0 entschärft: Beide können einen Block sofort bei bis zu 3 High-Bandwidth-Compact-Block-Peers anfordern.
Eine Race Condition bei der Erkennung von Selbstverbindungen beseitigt Version 27.2 von Bitcoin Core (#30394), FillPSBT-Aufrufe liefern nicht mehr fälschlich complete=true (#30357). Der Thread zum Laden der Blöcke und der Scheduler fahren nun in anderer Reihenfolge herunter (#30435), gebaut werden kann auch mit miniupnpc 2.2.8 und GCC 15.
Vor v25.0 konnten mutierte Blöcke eines einzelnen Peers in Bitcoin Core den Download-Status anderer Peers löschen, die denselben Block angekündigt hatten. Der Knoten vergaß so einen Compact Block, den er gerade noch rekonstruierte. Suhas Daftuar fiel das Problem auf, #27608 beschränkt jeden Peer auf seinen eigenen Status. CVE-2024-52921 ist als mittelschwer eingestuft.
Bitcoin-Core-Knoten vor v25.0 ließen sich aus der Ferne mit einer wiederholten blocktxn-Nachricht zu einem Block abschießen: Sie löste eine Assertion aus, die davon ausgeht, dass FillBlock nur einmal läuft. Eine Short-ID-Kollision war nicht nötig, denn derselbe Pfad ließ sich auch mit Transaktionen erreichen, die in der Merkle Root des Blocks fehlen. Niklas Gögge fand und behob den als hoch eingestuften Fehler CVE-2024-35202.
Anfang Mai 2023 bremste ein Schub an Netzwerkaktivität, verschärft durch Spionage-Knoten, die Verbreitung von Blöcken und Transaktionen: Das Sortieren übergroßer inv-to-send-Sets fraß fast die gesamte Zeit des P2P-Threads. Behoben hat das als mittelschwer eingestufte Problem Bitcoin Core v25.0 mit #27610; der Patch verwirft Transaktionen, die den Mempool verlassen haben, früher und leert die Sets mit zunehmender Größe schneller.
Mit Bitcoin Core 28.0 kommt Testnet4 (BIP94), dazu begrenztes Package Relay für Paare aus einem Parent und einem Child, standardkonforme TRUC-Transaktionen nach BIP 431 und der neue Output-Typ Pay To Anchor. -mempoolfullrbf steht nun standardmäßig auf 1, libbitcoinconsensus ist nach der Abkündigung in 27.0 verschwunden.
Ketten aus Headern mit niedriger Difficulty konnten Bitcoin-Core-Knoten vor v24.0.1 aus der Ferne zum Absturz bringen, eine einzige präparierte Kette ließ sich gegen jeden Knoten im Netz wiederverwenden. Der Fix in #25717 lässt den Knoten prüfen, ob eine Kette genug Arbeit enthält, bevor er sie speichert; damit waren auch Checkpoints gegen bekannte Angriffe nicht mehr nötig. Einstufung: hoch.
Ein Schwall von addr-Nachrichten konnte einen Bitcoin-Core-Knoten lahmlegen: 2^32 Einträge im addrman ließen einen 32-Bit-ID-Zähler überlaufen und lösten eine Assertion aus. Eugene Siegel meldete den als hoch eingestuften Fehler 2021, v22.0 enthält den Fix von Pieter Wuille.
Als UPnP-Gerät im lokalen Netz getarnt, konnte ein Angreifer einen Bitcoin-Core-Knoten mit aufgeblähten M-SEARCH-Antworten füttern, bis der Speicher ausging. Gefährdet waren nur Knoten, die mit -miniupnp gestartet wurden, ansonsten ist die Bibliothek standardmäßig aus. v22.0 behob den als niedrig eingestuften Fehler.