vote : Comment un mineur vote-t-il pour certains BIP ?

Voir ma réponse ici pour répondre à certaines de vos idées fausses. TL; DR  : les mineurs signalent une prise en charge par blocs de certains changements de règles afin de coordonner l’activation, et non de déterminer si elle est acceptée ou non.

En ce qui concerne le mécanisme réel utilisé pour signaler, un certain nombre a été utilisé dans le passé  :

Basé sur le temps  : BIP16, BIP30

Les premiers softforks (jusqu’à la mi-2012) utilisaient un simple mécanisme d’activation basé sur le temps  : le logiciel de nœud qui implémentait ces propositions appliquait les nouvelles règles sur tous les blocs avec un horodatage après une certaine date. Dans le cas de BIP16, cette date a été déterminée (et modifiée) en réponse à la signalisation des mineurs, mais cette signalisation était juste pour l’interprétation humaine ; les nœuds n’ont pris aucune action automatique en réponse.

Plus précisément, la signalisation utilisée ici consistait à placer une chaîne avec un message de support dans le champ scriptSig de la transaction coinbase, qui est par ailleurs libre pour les mineurs de mettre quoi que ce soit.

Signalisation en version bloc  : BIP34, BIP65, BIP66

Une génération ultérieure de softforks a utilisé le champ nVersion de l’en-tête de bloc pour la signalisation (jusqu’en 2015). Chacun de ceux-ci utilisait un numéro de version ultérieur (BIP34 utilisait la version 2 ; BIP66 utilisait la version 3 ; BIP65 utilisait la version 4).

Chaque fois que 750 blocs sortants numéro N-1000.N-1 (donc 75%) avaient le numéro de version de la proposition ou supérieur, le bloc N serait soumis aux règles de la proposition. Chaque fois que 950 des blocs numérotés N-1000.N-1 (donc 95%) le faisaient, le bloc suivant devrait également signaler pour lui – ce qui entraînerait un verrouillage final.

Signalisation basée sur les bits  : BIP68/112/113, BIP141/143/144, BIP91, BIP341/342

Le déploiement des temps de verrouillage relatifs (BIP68/112/113) et du témoin séparé (BIP141/143/144) a utilisé un mécanisme différent, qui avait son propre document, BIP9. Il spécifie l’utilisation d’un bit spécifique du champ nVersion de l’en-tête de bloc pour chaque proposition, et une machine à états finis pour déterminer quand signaler et quand activer. Son but est/était de permettre l’activation de plusieurs propositions simultanées, sans qu’il soit nécessaire d’en terminer une avant que la suivante puisse être déployée. C’était un inconvénient du mécanisme précédent, car il serait impossible d’activer la proposition avec la version 4 sans également signaler l’activation de la proposition avec la version 3.

Pour diverses raisons, le segwit n’était pas entièrement controversé et l’activation éventuelle s’est produite via une méta-proposition, BIP91. BIP91 lui-même a utilisé BIP9 pour s’activer, ce qui a ensuite rendu obligatoire la signalisation pour BIP141/143/144, ce qui a entraîné son activation en août 2017.

BIP341/342 activé en novembre 2021, à l’aide d’un mécanisme d’activation basé sur les bits de version modifiés avec un seuil d’activation inférieur et une hauteur d’activation minimale, dans ce que l’on a appelé l’approche «d’essai rapide».

L’avenir?

BIP30, BIP66, BIP141/143/144, BIP340/341/342).