Die Referenzimplementierung von Bitcoin. Ihre Website veröffentlicht Ankündigungen neuer Versionen, Sicherheitshinweise und Stellungnahmen des Projekts.
1486 Zeilen Code umfassen die Konsens- und P2P-Änderungen hinter SegWit, dazu kommen 3338 Zeilen Tests. Getestet wurde von Pieter Wuilles Version für die Elements-Sidechain 2015 über Segnet bis zum regulären Bitcoin-Testnet im Mai 2016. Schnorr-Signaturen und MAST gelten als spätere Upgrades, die SegWit erleichtern würde.
Bis Block 419328 müssen Miner handeln: Der CSV-Soft-Fork erreichte bei Block 417312 den Lock-in, nachdem 1946 von 2016 Blöcken (96,53 %) für BIP68, BIP112 und BIP113 signalisiert hatten. Alle Mining- und Backup-Knoten müssen Bitcoin Core oder Knots 0.12.1 laufen lassen, wer die Blockversion fest einprogrammiert hat, muss Bit 0 zurücksetzen.
Über Bits im Block-Header können Miner mit BIP9 die Bereitschaft für bis zu 29 parallele Soft Forks signalisieren. Ein Vorschlag erreicht den Lock-in, wenn 95 % der Blöcke in einem Fenster von 2016 Blöcken signalisieren, und wird ein Retarget später aktiv, andernfalls scheitert er am Timeout. Hält ein nicht signalisierender Block die neuen Regeln ein, wird er anders als bei IsSuperMajority nicht zum Orphan.
Peers mit Compact Block Relay (BIP152) tauschen zu jedem neuen Block eine Skizze aus, rund 9 KB bei einem durchschnittlichen Block von 1 MB, plus Overhead für Transaktionen, die dem Empfänger fehlen. In Live-Experimenten im High-Bandwidth-Modus mit bis zu 6 vorab mitgeschickten Transaktionen verbreiteten sich weit über 90 % der Blöcke ohne weitere Anfrage.
Das Signalisieren für den CSV-Soft-Fork beginnt um Mitternacht am 1. Mai 2016 mit Bitcoin Core 0.12.1, dem ersten Deployment über BIP9-Version-Bits. Es umfasst BIP68, BIP112 und BIP113; OP_CHECKSEQUENCEVERIFY erlaubt es, Coins nach der Bestätigung für eine festgelegte Zeit einzufrieren, worauf das Lightning Network angewiesen sein wird. Das P2P-Alert-System ist nun standardmäßig aus.
Marco Falke wird neuer Maintainer für Testing & QA bei Bitcoin Core, wie Wladimir van der Laan mitteilte. Er ist künftig für das Mergen von Pull Requests am Test-Framework zuständig, ein naheliegender Schritt nach einem Jahr Arbeit an Unit-Tests, Testabdeckung und Reviews anderer Contributors.
Für Sicherheitsprobleme und neue Releases gibt es nun eine eigene Ankündigungsliste von Bitcoin Core, nur auf Anmeldung und ausschließlich für Ankündigungen. Nutzer hatten sich einen Weg gewünscht, nur die kritischen Meldungen zu erhalten; das Projekt rechnet mit sehr wenigen Nachrichten.
Mit der ersten erfolgreichen Zero-Knowledge Contingent Payment auf Bitcoin wechselte die Lösung eines 16x16-Sudokus für 0,10 BTC den Besitzer, live vorgeführt auf der Financial Cryptography 2016 auf Barbados. Verkäufer war Sean Bowe vom Zcash-Team, der auch fast die gesamte Technik baute. Das Protokoll gibt die Daten nur gegen Bezahlung frei, einen Dritten als Schiedsrichter braucht es nicht.
OpenSSL ist in Bitcoin Core 0.12.0 raus aus der Signaturprüfung, an seine Stelle tritt libsecp256k1, das Reindexing und die Validierung neuer Blöcke auf weniger als die Hälfte der bisherigen Zeit drückt. Der Mempool erhält eine Standardgrenze von 300 MB, was einen Angriffsweg auf Knoten mit wenig RAM schließt. Ebenfalls neu: Opt-in-Replace-by-Fee (BIP 125) und -maxuploadtarget zur Begrenzung des Upload-Traffics.
Die Website, auf der das Bitcoin-Paper zuerst lag, gehört nicht zum Projekt, stellt Bitcoin Core klar; es hat eine eigene offizielle Website. Entwickelt wird auf IRC, GitHub und der Mailingliste bitcoin-dev. Für andere Foren übernimmt das Projekt keine Verantwortung, und es bittet die Community, auf Brigading und Denial-of-Service-Angriffe zu verzichten.
Third-Party-Malleability endet für Transaktionen, deren Inputs allesamt SegWit-Ausgaben sind, denn die Signaturen wandern in einen Witness, der nicht mehr in die txid einfließt. Davon profitieren Wallet-Entwickler ebenso wie das Lightning Network. Auch das Signatur-Hashing wird linear, jedes Byte wird höchstens zweimal gehasht; nach dem alten Verfahren brauchte die Validierung eines einzigen Blocks schon einmal 25 Sekunden.
Entwickler können Segregated Witness jetzt in einem eigenen Netz testen, indem sie den segwit-Branch kompilieren und bitcoind und bitcoin-cli um -segnet ergänzen. Ledger, Trezor, Electrum und Bitgo haben SegWit-Unterstützung zugesagt, mSIGNA und Green Address bieten frühe Vorschauen an.
Ein Video bildet die Commit-Aktivität im Bitcoin-Core-Repository im Jahr 2015 ab, einem Jahr mit 2 Hauptversionen, 5 Wartungsreleases und zwei aktivierten Soft Forks: BIP66 und BIP65, wobei Letzterer CHECKLOCKTIMEVERIFY einführte. Reviewer, Tester und Übersetzer tauchen in Commit-Daten nicht auf, merkt das Projekt an.
Über die Konsensregeln entscheidet nicht das Team von Bitcoin Core, sagen seine Contributors, sondern die Nutzer mit der Wahl ihrer Software; deshalb kommt sie ohne Auto-Update. Sie bevorzugen Soft Forks, Hard Forks bleiben seltenen Fällen mit nahezu einhelliger Zustimmung vorbehalten, und extrem hohe Skalierung sehen sie in zusätzlichen Schichten auf dem Protokoll.
Unter dem neuen Kostenlimit von SegWit können Blöcke knapp 4 MB erreichen, nach den Berechnungen von Anthony Towns kommt ein Block aus Single-Signature-P2PKH-Transaktionen aber auf etwa 1,6 MB, einer mit 2-von-2-Multisig auf rund 2,0 MB. Der vorläufige Zeitplan der FAQ sieht SegWit in 0.13.1 im Oktober 2016 vor, 2017 sollen Weak Blocks, IBLT oder Lightning folgen.
57 Personen, darunter Pieter Wuille, Gregory Maxwell und Wladimir J. van der Laan, unterstützen die Kapazitäts-Roadmap und nennen sie die beste Fortsetzung ihrer Skalierungsarbeit innerhalb von Bitcoin Core. Die Liste bleibt für weitere Unterschriften offen.
Gregory Maxwells Roadmap, zum Abschluss von Scaling Bitcoin Hong Kong an die Mailingliste bitcoin-dev geschickt, baut auf libsecp256k1, BIP9-Versionbits und Pieter Wuilles Segregated Witness auf. Er berichtet, dass ConnectTip in 0.12 siebenmal so schnell läuft, und beschreibt SegWit als Soft Fork, der Signaturen aus dem aktuellen Blockgrößenlimit herausnimmt, was schlimmstenfalls einer 4-MB-Erhöhung gleichkommt.
Technische Contributors, darunter Wladimir J. van der Laan und Pieter Wuille, bitten in einem Brief die Community, Skalierungsvorschläge nicht vorzuverurteilen. Stattdessen verweisen sie auf den Konsensprozess und zwei offene Scaling-Bitcoin-Workshops: Montreal am 12. und 13. September und Hongkong am 6. und 7. Dezember.