Die Referenzimplementierung von Bitcoin. Ihre Website veröffentlicht Ankündigungen neuer Versionen, Sicherheitshinweise und Stellungnahmen des Projekts.
Über den bereits bekannten Absturz hinaus konnte ein Miner mit CVE-2018-17144 in den Versionen 0.15.X bis 0.16.2 die Bitcoin-Geldmenge aufblähen, indem er einen Output innerhalb einer Transaktion zweimal ausgab. Diesen Teil hielten die Entwickler zurück, damit Systeme Zeit für den Wechsel auf 0.16.3 oder 0.17.0rc4 hatten. Mehr als die Hälfte der Hashrate gilt als gepatcht, Angriffsversuche sind nicht bekannt, Betroffene sollen dringend aktualisieren.
CVE-2018-17144 lässt Bitcoin Core 0.14.0 bis 0.16.2 bei einem Block abstürzen, der eine Transaktion mit zweimal ausgegebenem Input enthält; Nutzer sollen sofort auf 0.16.3 aktualisieren. Erzeugen kann einen solchen Block nur ein Miner, der bereit ist, auf mindestens 12,5 BTC zulässige Einnahmen zu verzichten.
Der RPC verifytxoutproof fällt in Bitcoin Core 0.16.2 nicht mehr auf einen Anfang Juni bekannt gewordenen, teuren Angriff auf SPV-Beweise herein, echte SPV-Clients bleiben aber angreifbar. Ein weiterer Fix sorgt dafür, dass abandontransaction alle Nachfahren einer Transaktion verwirft und nicht bei ihren Kindern stehen bleibt.
OP_CODESEPARATOR in Legacy-Signaturskripten leitet Bitcoin Core 0.16.1 nicht mehr weiter; die Policy-Änderung erleichtert es, künftige Fixes für langsam zu validierende Blöcke auszurollen. Miner verlieren die Option -blockmaxsize zugunsten von -blockmaxweight und bekommen einen Fix für einen Bug, der sie bei zwei kurz aufeinander gefundenen Blöcken Einnahmen hätte kosten können.
SegWit wird in Bitcoin Core 0.16.0 zum Wallet-Standard: Neue Adressen sind p2sh-segwit, sofern -addresstype nichts anderes festlegt, und native bc1-Adressen nach BIP173 lassen sich erzeugen und bezahlen. Neue Wallets sind ausschließlich HD, ältere Versionen weisen sie ab, und die Sendemaske der GUI aktiviert BIP125-RBF nun standardmäßig.
Als Vorsorge gegen künftige Netz-Forks trennt Bitcoin Core 0.15.1 beim ersten Synchronisieren Peers, deren Chain unter der minimum-chain-work liegt, dazu ausgehende Peers, die bekanntermaßen ungültige Header liefern. Hängt die Chain-Spitze 30 Minuten fest, baut der Knoten nun eine zusätzliche ausgehende Verbindung auf. Miner können blockmaxsize nicht mehr direkt nutzen: Die Option ist veraltet und impliziert nur noch ein Gewichtslimit.
Ein Absturz der GUI beim Start war der Anlass für Bitcoin Core 0.15.0.1: Manche Clients scheiterten beim Upgrade auf 0.15.0 an einer benutzerdefinierten Gebühreneinstellung, die die Oberfläche nicht mehr anbietet. Ein minimaler Patch, #11332, fängt den ungültigen Wert ab.
Gebührenschätzungen reichen in Bitcoin Core 0.15.0 statt 25 nun 1008 Blöcke voraus, und GUI-Nutzer können die Gebühr unbestätigter Transaktionen per Replace-By-Fee erhöhen. Eine Chainstate-Datenbank pro Output beschleunigt den Initial Block Download um 30 bis 40 %. Die Umstellung läuft beim ersten Start automatisch und dauert etwa 5 bis 30 Minuten.
Regelmäßige Contributors von Bitcoin Core haben nichts mit btc1 zu tun, der Implementierung von Segwit2x, und das Projekt widerspricht der Behauptung, es handle sich um ein notwendiges Update; es spricht von einem umstrittenen Bruch mit den Netzwerkregeln. SegWit, der in wenigen Tagen fällige Soft Fork, hat mit diesem Hard Fork nichts zu tun und verlangt von den meisten Nutzern nichts. Zudem warnt die Erklärung, dass Segwit2x keinen starken Replay-Schutz plant.
Wer UPnP aktiviert hat, soll Bitcoin Core 0.14.2 umgehend installieren: Ein Integer-Signedness-Fehler im mitgelieferten miniupnpc, CVE-2017-8798, erlaubt Angreifern im lokalen Netz einen Denial-of-Service und womöglich weiteren Schaden. UPnP bleibt standardmäßig aus, Knoten, die es nie eingeschaltet haben, sind also nicht betroffen.
Miner ohne SegWit können getblocktemplate auch nach der Aktivierung weiter nutzen, denn Bitcoin Core 0.14.1 entfernt SegWit-Transaktionen aus dem Template. Der Standardwert von -dbcache liegt jetzt bei 450 MiB, und das Limit hält nun auch bei Flush-Spitzen. Umbenannte Argumente in createrawtransaction und disconnectnode brechen Aufrufe, die benannte Argumente aus 0.14.0 verwenden.
Die Wallet eines neuen Knotens könnte schon vor dem Ende der Synchronisierung senden und empfangen: Das sieht der hybride Full-Block-SPV-Modus auf der Roadmap von Bitcoin Core vor. Er holt Blöcke ab dem ältesten Schlüssel der Wallet zuerst, während die volle Validierung im Hintergrund weiterläuft. Die Datenlecks von Bloom-Filtern entfallen auf Kosten von mehr Bandbreite, Zahlungen sollten 6 oder mehr Bestätigungen abwarten.
Würden Schnorr-Signaturen ECDSA ablösen, schrumpfte ein 50-von-50-Multisig auf die Größe einer Ausgabe mit einem einzigen Schlüssel und verbärge seine Policy vor Beobachtern. Als Haupthindernis nennt die Roadmap von Bitcoin Core die Cancellation, bei der ein bösartiger Unterzeichner den Schlüssel eines anderen Nutzers subtrahiert. Delinearisierung kontert diesen Angriff, ihr Sicherheitsbeweis steckt allerdings noch im Peer Review.
Signatur-Caching in Bitcoin-Qt 0.7.0, Ultraprune mit LevelDB in 0.8.0 und Headers-First-Sync in Bitcoin Core 0.10 sind Thema in Teil 1 des Rückblicks auf die Beschleunigungen der Referenzsoftware. Allein die parallele Skriptprüfung brachte in Benchmarks der Entwickler 35 bis 100 %.
Neue Knoten schlossen den Initial Block Download mit Bitcoin Core 0.14.0 in einem Test auf Amazon EC2 mit Standardeinstellungen 5,7-mal so schnell ab wie mit 0.13.2: 6 Stunden 24 Minuten gegenüber 1 Tag, 12 Stunden und 40 Minuten. Den Gewinn bringen Assumed-Valid-Blöcke und ein zwischen Mempool und UTXO-Cache geteilter Speicher. Wallets erhalten außerdem optionales Fee Bumping, standardmäßig aus.
Stößt eine Wallet-Zahlung an das Limit für unbestätigte Ketten, gibt Bitcoin Core 0.13.2 keinen RPC-Fehler mehr zurück. Der Aufruf meldet Erfolg, die Aufnahme in den Mempool wird beim Rebroadcast erneut versucht, ohne Neustart. Gebührenschätzungen für ein Ziel von 1 Block sind deaktiviert, der Umgang mit ungültigen Compact Blocks ist korrigiert.
In P2SH verpacktes SegWit kostet am meisten Bytes: 19 % mehr bei P2WSH/P2SH und 11 % bei P2WPKH/P2SH für eine Transaktion von 180 Byte, so die Aufstellung von Bitcoin Core zu den Folgen von BIP141. Die Validierung braucht pro Transaktion etwa fünf zusätzliche SHA256-Hashes. Als Risiken werden Bugs, größere Blöcke und niedrigere Gebühren abgewogen, zur Aktivierung beziehen die Autoren keine Position.
Miner erhalten mit Bitcoin Core 0.13.1 den Code, um für den SegWit-Soft-Fork zu signalisieren; das Signalisieren beginnt ab dem 15. November 2016 mit der nächsten Retarget-Periode. Für den Lock-in sind 95 % der Blöcke einer Periode von 2016 Blöcken nötig, die Aktivierung folgt eine Periode später. Wallets bleiben kompatibel, handeln müssen also womöglich nur Miner.
Zwei Gruppen muss SegWit gewinnen: Miner, die in 95 % der Blöcke einer Retarget-Periode Bit 1 signalisieren, und genügend Full Nodes mit Bitcoin Core 0.13.1 oder einer kompatiblen Implementierung. Das Signalisieren beginnt mit dem ersten Retarget am oder nach dem 15. November 2016. Eigene Schritte gibt es für Miner, Knotenbetreiber, Wallet-Nutzer und Entwickler, auch für alle, die bewusst nicht aktualisieren.
SegWit-Code zieht in Bitcoin Core 0.13.0 ein, bleibt im Mainnet aber inaktiv; nutzbar wird er dort erst mit einer späteren Version, voraussichtlich 0.13.1. Compact Block Relay (BIP152) glättet Bandbreitenspitzen, neue Wallets nutzen HD-Schlüssel nach BIP32, sodass ein einziges Backup alle künftigen privaten Schlüssel abdeckt. Auch Builds für Linux auf ARM gehören jetzt zu den offiziellen Downloads.