Soft fork activé par les mineurs

Les mineurs ne décident pas si une règle est bonne. Ils déclarent qu'ils sont assez nombreux à être prêts à l'appliquer pour que ce durcissement n'écarte pas de travail honnête. Selon le BIP-9, le seuil est de 1 916 blocs sur 2 016 au cours d'une même période de difficulté, soit 95 pour cent, et le décompte repart de zéro à chaque période tant qu'il n'est pas atteint.

Comment cela fonctionne

Le signalement réutilise un champ qui existe déjà dans chaque en-tête de bloc, si bien qu'aucun nouveau type de message ni registre n'est nécessaire.

La méthode d'origine, introduite avec le BIP-34 en 2013, se contentait d'élever le numéro de version de bloc et de compter à rebours : une règle devenait obligatoire dès que 950 des 1 000 derniers blocs portaient la version supérieure, après une étape de 750 sur 1 000 durant laquelle elle ne liait que les blocs qui la revendiquaient. Elle fonctionnait, mais les versions devaient être déployées strictement l'une après l'autre, si bien que deux propositions ne pouvaient jamais être en cours en même temps.

Le BIP-9 a remplacé le compteur par 29 bits indépendants. Chaque proposition revendique un bit et une heure de début, les mineurs activent ce bit dans les blocs qu'ils minent, et chaque nœud totalise ce bit sur toute une période de difficulté de 2 016 blocs. Atteindre le seuil fait passer le déploiement à verrouillé, et l'application commence une période complète plus tard, ce qui laisse environ deux semaines de plus à quiconque n'a pas mis à jour son logiciel. Un déploiement qui n'atteint jamais le seuil expire à son délai et le bit est libéré pour être réutilisé.

Deux variantes comptent sur le plan historique. Le BIP-91 a compressé tout le processus à 80 pour cent de 336 blocs afin que le signalement de SegWit puisse devenir obligatoire rapidement ; il a été verrouillé au bloc 476 768 le 20 juillet 2017 et l'application a commencé au bloc 477 120 le 23 juillet 2017. Speedy Trial, livré dans Bitcoin Core 0.21.1 le 1er mai 2021, a conservé le décompte du BIP-9 mais abaissé le seuil à 1 815 blocs sur 2 016, limité la tentative à environ trois mois et séparé le verrouillage de l'activation en fixant à l'avance une hauteur d'activation minimale.

Où cela se voit

Les explorateurs de blocs affichent le champ de version, généralement sous forme d'une valeur hexadécimale de huit caractères, et pendant un déploiement en cours ils montrent quel bit est activé. Une version commençant par 0x20 signifie que le bloc utilise bel et bien les bits de version ; les bits de poids faible sont les signaux individuels.

Le signalement laisse aussi une trace plus simple dans la transaction coinbase, où les pools écrivent du texte libre. La chaîne « /P2SH/ » marquait le soutien à pay to script hash en 2012, et « NYA » marquait le New York Agreement en 2017. Ce champ relève de la décoration plutôt que du protocole, mais c'est souvent là qu'un désaccord devient visible en premier.

Pour quiconque détient du bitcoin, ce qu'il faut retenir d'un pourcentage de signalement, c'est ce qu'il n'est pas. Ce n'est pas un référendum, ce n'est pas pondéré par la détention, et un pool qui signale un bit parle pour de la puissance de hachage que d'autres lui ont louée. Une règle peut atteindre 95 pour cent et rester impopulaire, et une règle peut être appliquée par des utilisateurs sans aucun soutien de mineurs.

Soft fork activé par les mineurs vs soft fork activé par les utilisateurs

Les deux répondent à des questions différentes. Un soft fork activé par les mineurs demande quand l'application doit commencer et laisse la puissance de hachage fixer la date. Un soft fork activé par les utilisateurs fixe d'abord la date et laisse les mineurs s'y conformer ou voir leurs blocs rejetés. En 2017, les deux étaient sur la table en même temps, et l'enchaînement est tout l'intérêt : la voie des mineurs était bloquée depuis des mois, une échéance appliquée par les utilisateurs était programmée, et la voie des mineurs a abouti quelques semaines après que cette échéance est devenue crédible.