Les changements de consensus et de pair-à-pair derrière segwit touchent 1486 lignes de code, plus 3338 lignes de tests. Les essais sont passés de la version de Pieter Wuille sur la sidechain Elements, en 2015, à segnet, puis au testnet habituel de Bitcoin en mai 2016. Les signatures de Schnorr et MAST sont citées parmi les évolutions futures que segwit faciliterait.
Les mineurs ont jusqu’au bloc 419328 pour agir : le soft fork CSV s’est verrouillé au bloc 417312 après que 1946 blocs sur 2016 (96,53 %) ont signalé BIP68, BIP112 et BIP113. Tous les nœuds de minage et de secours doivent tourner sous Bitcoin Core ou Knots 0.12.1, et quiconque code en dur la version de bloc doit désactiver le bit 0.
Grâce à BIP9, les mineurs peuvent signaler qu’ils sont prêts pour 29 soft forks simultanés au maximum, via des bits de l’en-tête de bloc. Une proposition se verrouille quand 95 % des blocs d’une fenêtre de 2016 blocs la signalent, puis s’active un ajustement plus tard, ou échoue à son expiration. Contrairement à IsSuperMajority, BIP9 ne rend pas orphelin un bloc sans signal qui respecte les nouvelles règles.
Les pairs qui utilisent le relais de compact blocks (BIP152) s’échangent une esquisse de chaque nouveau bloc, environ 9 ko pour un bloc moyen de 1 Mo, plus un surcoût pour les transactions qui manquent au destinataire. Lors d’essais réels à haut débit avec jusqu’à 6 transactions préremplies, bien plus de 90 % des blocs se sont propagés sans requête supplémentaire.
Le signalement du soft fork CSV démarre à minuit le 1er mai 2016 avec Bitcoin Core 0.12.1, premier déploiement passant par les version bits de BIP9. Il couvre BIP68, BIP112 et BIP113 ; OP_CHECKSEQUENCEVERIFY permet de geler des pièces pendant une durée donnée après confirmation, ce dont dépendra le Lightning Network. Le système d’alerte p2p est désormais désactivé par défaut.
Marco Falke devient le nouveau mainteneur Testing & QA de Bitcoin Core, annonce Wladimir van der Laan. Il prend en charge la fusion des pull requests du framework de test, suite logique d’une année passée sur les tests unitaires, la couverture et la relecture du travail d’autres contributeurs.
Les failles de sécurité et les nouvelles versions ont désormais leur liste d’annonces Bitcoin Core, sur inscription et réservée aux annonces. Des utilisateurs réclamaient un moyen de ne recevoir que les alertes critiques, et le projet s’attend à un très faible volume.
La solution d’un sudoku 16x16 s’est vendue 0,10 BTC lors du premier Zero-Knowledge Contingent Payment réussi sur Bitcoin, démontré en direct à la conférence Financial Cryptography 2016, à la Barbade. Sean Bowe, de l’équipe Zcash, était le vendeur et a assuré presque toute l’ingénierie. Avec ce protocole, les données ne changent de mains que si le paiement a lieu, sans tiers pour arbitrer.
OpenSSL ne sert plus à vérifier les signatures dans Bitcoin Core 0.12.0, au profit de libsecp256k1, qui réduit de plus de moitié le temps de réindexation et de validation des nouveaux blocs. Les mempools reçoivent un plafond par défaut de 300 Mo, qui supprime un moyen de planter les nœuds à faible RAM. Également au menu : Replace-by-Fee opt-in (BIP 125) et -maxuploadtarget pour limiter le trafic montant.
Bitcoin Core précise que le site qui a hébergé en premier le livre blanc de Bitcoin n’est pas affilié au projet, lequel a son propre site officiel. Le développement se déroule sur IRC, GitHub et la liste de diffusion bitcoin-dev. Le projet décline toute responsabilité pour les autres forums et demande aux membres de la communauté de ne pas se livrer au brigading ni à des attaques par déni de service.
Fin de la malléabilité par des tiers pour les transactions dont toutes les entrées sont des dépenses segwit, les signatures passant dans un witness qui n’alimente plus le txid. Les auteurs de portefeuilles comme le Lightning Network y gagnent. Le hachage des signatures devient lui aussi linéaire, chaque octet étant haché au plus deux fois ; avec l’ancien schéma, la validation d’un seul bloc a déjà pris 25 secondes.
Les développeurs peuvent désormais tester Segregated Witness sur son propre réseau en compilant la branche segwit et en ajoutant -segnet à bitcoind et bitcoin-cli. Ledger, Trezor, Electrum et Bitgo ont annoncé qu’ils prendraient en charge segwit, tandis que mSIGNA et Green Address en proposent déjà des préversions.
Une vidéo retrace l’activité de commits de 2015 dans le dépôt Bitcoin Core, une année marquée par 2 versions majeures, 5 versions de maintenance et deux soft forks activés : BIP66 et BIP65, ce dernier ajoutant CHECKLOCKTIMEVERIFY. Relecteurs, testeurs et traducteurs n’apparaissent pas dans ces données, rappelle le projet.
Les règles de consensus ne relèvent pas de l’équipe de Bitcoin Core, affirment ses contributeurs : ce sont les utilisateurs qui tranchent en choisissant le logiciel qu’ils font tourner, raison pour laquelle il n’a pas de mise à jour automatique. Ils privilégient les soft forks, réservent les hard forks à de rares cas de quasi-unanimité et voient dans des couches supplémentaires au-dessus du protocole la voie vers une très grande échelle.
Sous la nouvelle limite de coût de segwit, les blocs peuvent atteindre un peu moins de 4 Mo, mais les calculs d’Anthony Towns situent un bloc de transactions P2PKH à signature unique autour de 1,6 Mo et un bloc de multisig 2-sur-2 autour de 2,0 Mo. Le calendrier provisoire de la FAQ prévoit le déploiement de segwit dans 0.13.1 en octobre 2016, suivi en 2017 des weak blocks, d’IBLT ou de Lightning.
En signant la feuille de route sur la capacité, 57 personnes, dont Pieter Wuille, Gregory Maxwell et Wladimir J. van der Laan, y voient la meilleure suite à leur travail sur le passage à l’échelle au sein de Bitcoin Core. La liste reste ouverte à d’autres signatures.
La feuille de route de Gregory Maxwell, envoyée à la liste bitcoin-dev à la clôture de Scaling Bitcoin Hong Kong, s’appuie sur libsecp256k1, les versionbits de BIP9 et Segregated Witness de Pieter Wuille. Il annonce un ConnectTip 7 fois plus rapide dans 0.12 et présente segwit comme un soft fork qui sort les signatures de la limite actuelle de taille des blocs, soit une hausse à 4 Mo au pire.
Des contributeurs techniques, dont Wladimir J. van der Laan et Pieter Wuille, ont signé une lettre demandant à la communauté de ne pas préjuger des propositions de passage à l’échelle. Ils renvoient plutôt au processus de consensus et à deux ateliers Scaling Bitcoin ouverts : Montréal les 12 et 13 septembre, Hong Kong les 6 et 7 décembre.