Au-delà du plantage déjà public, CVE-2018-17144 permettait à un mineur de gonfler l’offre de bitcoins dans les versions 0.15.X à 0.16.2 en dépensant deux fois une sortie au sein d’une même transaction. Les développeurs avaient gardé cet aspect pour eux afin de laisser aux systèmes le temps de passer à 0.16.3 ou 0.17.0rc4. Plus de la moitié du hashrate serait corrigée, aucune tentative d’exploitation n’est connue, et les utilisateurs concernés sont invités à mettre à jour.
À cause de CVE-2018-17144, Bitcoin Core 0.14.0 à 0.16.2 plante face à un bloc contenant une transaction qui dépense deux fois la même entrée, et les utilisateurs sont priés de passer immédiatement à 0.16.3. Seul un mineur prêt à renoncer à au moins 12,5 BTC de revenus autorisés pouvait produire un tel bloc.
La commande RPC verifytxoutproof de Bitcoin Core 0.16.2 ne cède plus à une attaque coûteuse contre les preuves SPV révélée début juin, même si les vrais clients SPV restent exposés. Autre correctif : abandontransaction écarte tous les descendants d’une transaction au lieu de s’arrêter à ses enfants.
Bitcoin Core 0.16.1 ne relaie plus OP_CODESEPARATOR dans les scripts de signature legacy, un changement de règles qui facilite le déploiement de futurs correctifs contre les blocs lents à valider. Les mineurs perdent l’option -blockmaxsize au profit de -blockmaxweight et bénéficient de la correction d’un bug qui pouvait leur coûter du revenu quand ils produisaient deux blocs coup sur coup.
Segwit devient le réglage par défaut des portefeuilles dans Bitcoin Core 0.16.0 : les nouvelles adresses sont en p2sh-segwit sauf indication contraire de -addresstype, et les adresses natives bc1 de BIP173 peuvent être générées et payées. Les nouveaux portefeuilles sont uniquement HD et les versions antérieures les rejettent, tandis que l’écran d’envoi de l’interface graphique active désormais RBF (BIP125) par défaut.
Par précaution contre de futurs forks du réseau, Bitcoin Core 0.15.1 écarte pendant la synchronisation initiale les pairs proposant une chaîne sous minimum-chain-work, ainsi que les pairs sortants qui servent des en-têtes connus comme invalides. Une tête de chaîne bloquée depuis 30 minutes déclenche désormais une connexion sortante supplémentaire. Les mineurs perdent l’usage direct de blockmaxsize, déprécié et qui n’implique plus qu’une limite de poids.
Un plantage de l’interface graphique au démarrage a motivé Bitcoin Core 0.15.0.1 : certains clients passés à 0.15.0 butaient sur un réglage de frais personnalisé que l’interface ne propose plus. Un correctif minimal, #11332, gère cette valeur invalide.
Les estimations de frais de Bitcoin Core 0.15.0 portent jusqu’à 1008 blocs, contre 25 auparavant, et l’interface graphique permet d’augmenter les frais d’une transaction non confirmée grâce à Replace-By-Fee. Une base chainstate organisée par sortie accélère de 30 à 40 % le téléchargement initial des blocs. Sa conversion se fait automatiquement au premier démarrage et prend de 5 à 30 minutes environ.
Les contributeurs réguliers de Bitcoin Core n’ont aucun lien avec btc1, l’implémentation de Segwit2x, et le projet récuse l’idée d’une mise à jour nécessaire, y voyant une rupture contestée avec les règles du réseau. Segwit, le soft fork attendu d’ici quelques jours, n’a rien à voir avec ce hard fork et n’impose rien à la plupart des utilisateurs. Le communiqué prévient aussi que Segwit2x ne prévoit pas de protection forte contre le rejeu.
Quiconque a activé UPnP est prié d’installer sans attendre Bitcoin Core 0.14.2 : une erreur de signe d’entier dans le miniupnpc embarqué, CVE-2017-8798, permet à un attaquant du réseau local de provoquer un déni de service, voire d’autres dégâts. UPnP reste désactivé par défaut, les nœuds qui ne l’ont jamais activé ne sont donc pas concernés.
Les mineurs non segwit pourront continuer d’utiliser getblocktemplate après l’activation, car Bitcoin Core 0.14.1 retire du modèle les transactions segwit. La valeur par défaut de -dbcache passe à 450 Mio et la limite tient désormais lors des pics de flush. Des arguments renommés dans createrawtransaction et disconnectnode cassent les appels qui utilisent les arguments nommés de 0.14.0.
Le portefeuille d’un nouveau nœud pourrait envoyer et recevoir avant la fin de la synchronisation avec le mode hybride SPV à blocs complets inscrit à la feuille de route de Bitcoin Core : les blocs sont récupérés à partir de la clé la plus ancienne du portefeuille, pendant que la validation complète se poursuit en arrière-plan. Les fuites de confidentialité des filtres de Bloom disparaissent au prix d’une bande passante accrue, et les paiements devraient attendre au moins 6 confirmations.
Remplacer ECDSA par les signatures de Schnorr ramènerait un multisig 50-sur-50 à la taille d’une dépense à clé unique et masquerait sa politique aux observateurs. La feuille de route de Bitcoin Core désigne comme principal obstacle l’annulation (cancellation), où un signataire malveillant soustrait la clé d’un autre utilisateur. La délinéarisation répond à cette attaque, même si sa preuve de sécurité est encore en cours de relecture par les pairs.
Le cache de signatures de Bitcoin-Qt 0.7.0, Ultraprune avec LevelDB dans 0.8.0 et la synchronisation headers-first de Bitcoin Core 0.10 figurent dans le premier volet de cette rétrospective sur les gains de vitesse du logiciel de référence. La vérification parallèle des scripts a apporté à elle seule de 35 à 100 % dans les benchmarks des développeurs.
Les nouveaux nœuds ont terminé le téléchargement initial des blocs 5,7 fois plus vite sous Bitcoin Core 0.14.0 que sous 0.13.2 lors d’un test sur Amazon EC2 avec les réglages par défaut : 6 h 24 contre 1 jour 12 h 40. Ce gain vient des blocs présumés valides et de la mémoire partagée entre le mempool et le cache d’UTXO. Les portefeuilles gagnent aussi une augmentation de frais facultative, désactivée par défaut.
Les envois de portefeuille qui butent sur la limite des chaînes non confirmées ne renvoient plus d’erreur RPC dans Bitcoin Core 0.13.2. Ils sont donnés pour réussis, et l’insertion dans le mempool est retentée à la rediffusion, sans redémarrage. Les estimations de frais pour une cible d’un bloc sont désactivées, et le traitement des compact blocks invalides est corrigé.
C’est l’encapsulation de segwit dans P2SH qui coûte le plus en octets : 19 % de plus pour P2WSH/P2SH et 11 % pour P2WPKH/P2SH sur une transaction de 180 octets, selon le décompte de Bitcoin Core sur ce qu’apporterait BIP141. La validation demande environ cinq hachages SHA256 de plus par transaction. Bugs, blocs plus gros et frais plus bas figurent parmi les risques examinés, et les auteurs ne prennent pas position sur l’activation.
Bitcoin Core 0.13.1 donne aux mineurs de quoi signaler le soft fork segwit : le signalement ouvre à partir du 15 novembre 2016, au début de la période d’ajustement suivante. Le verrouillage exige 95 % des blocs d’une période de 2016 blocs, et l’activation intervient une période plus tard. Les portefeuilles restent compatibles, si bien que seuls les mineurs pourraient avoir à agir.
Deux groupes doivent suivre pour que segwit aboutisse : les mineurs, qui signalent le bit 1 dans 95 % des blocs sur une période d’ajustement, et suffisamment de nœuds complets sous Bitcoin Core 0.13.1 ou une implémentation compatible. Le signalement ouvre au premier ajustement tombant le 15 novembre 2016 ou après. Des marches à suivre distinctes s’adressent aux mineurs, aux opérateurs de nœuds, aux utilisateurs de portefeuilles et aux développeurs, y compris à ceux qui choisissent de ne pas mettre à jour.
Le code de segwit entre dans Bitcoin Core 0.13.0 mais reste inactif sur le mainnet ; pour l’y utiliser, il faudra une version ultérieure, a priori 0.13.1. Le relais de compact blocks (BIP152) atténue les pics de bande passante, et les nouveaux portefeuilles utilisent des clés HD BIP32 : une seule sauvegarde couvre toutes les futures clés privées. Des builds Linux ARM rejoignent aussi les téléchargements officiels.
