Bitcoin Core : mise à jour softfork CSV pour améliorer la fonctionnalité et la sécurité des transactions

Chapô : Un soft fork des règles de consensus Bitcoin, connu sous le nom de « CSV », est sur le point d'être activé, avec 96,53 % des blocs déjà signalés comme prêts. Les mineurs et les exploitants de pools doivent procéder à une mise à jour urgente vers Bitcoin Core 0.12.1 ou un logiciel compatible avant le bloc #419328 pour éviter des problèmes majeurs. Des instructions précises concernant la version du bloc et l'utilisation du champ nLockTime sont également fournies.

Le soft fork CSV atteint son seuil d'activation

Le soft fork « CSV » a atteint le seuil « verrouillé » nécessaire pour son activation. Dans un échantillon de 2016 blocs allant du #415296 au #417311, 1946 blocs (soit 96,53 %) ont signalé leur préparation pour les mises à jour BIP68, BIP112 et BIP113, qui composent le soft fork CSV. À partir du bloc #417312 (21 juin 2016), ce soft fork entre dans une période de grâce « verrouillée » de deux semaines jusqu'au bloc #419327. Passé ce délai, les nouvelles règles seront appliquées par le réseau et l’activation sera irréversible sans un recul massif de la blockchain.

Tous les mineurs doivent mettre à jour leur logiciel

Durant cette période critique, tous les mineurs doivent obligatoirement passer à Bitcoin Core 0.12.1 ou toute autre implémentation prenant en charge le soft fork CSV. Actuellement, seules les versions Bitcoin Core et Knots 0.12.1 supportent cette mise à jour essentielle.

Il est crucial que chaque mineur vérifie que tous ses nœuds miniers ainsi que ceux de sauvegarde sont correctement mis à niveau. Ne pas effectuer cette mise à jour pourrait entraîner la génération de blocs invalides ou faire en sorte que vos nœuds s'appuient sur des blocs non valides, engendrant ainsi des fourches dans la chaîne et des pertes financières tant pour les mineurs que pour l’ensemble des utilisateurs de Bitcoin.

Les dangers du codage manuel de la version du bloc

Bien que Bitcoin Core définisse automatiquement la version selon les besoins d'un système sûr et stable, certains mineurs choisissent encore de coder manuellement leurs numéros de version des blocs.

Cette pratique est fortement déconseillée car elle peut introduire un risque potentiel dans l'écosystème Bitcoin ; si un mineur dispose accidentellement d’un nœud ne suivant pas ces règles indiquées par sa version du bloc, cela pourrait mener à la production et au suivi d'une chaîne non valide.

Dans le cadre actuel du soft fork BIP9 utilisé ici, aucun bloc ne sera orphelin même avec une mauvaise version (tant qu'elle est >=4). C'est pourquoi il n'y a aucune incitation à coder manuellement cette version qui pourrait augmenter inutilement les risques d’erreurs humaines.

Si vous avez codé manuellement votre version en dépit des recommandations données précédemment, il est impératif maintenant désactiver le bit 0 lié au CSV avant le bloc #419328 afin d'éviter tout message erroné dans vos journaux liés aux opérations conformes au BIP9.

Faire attention au champ nLockTime lors de la génération

L'utilisation rare mais délicate du champ nLockTime nécessite également une attention particulière en raison de l'activation imminente du BIP113.

Tout mineur interférant avec ce champ doit s'assurer qu'une valeur interprétée comme un horodatage UNIX soit inférieure à celle médiane des horodatages des derniers blocs sauf si sa valeur nSequence est fixée exactement à 0xffffffff.

Pour ceux ne utilisant pas ce champ dans leur transaction générative : utilisez simplement une valeur égale à zéro pour éviter toute complication possible pouvant mener vers une fourchette indésirable ou perte monétaire significative tant pour eux-mêmes que pour l'ensemble des utilisateurs Bitcoin impliqués.