Questions fréquentes sur les bits de version destinés aux mineurs

Chapô : Le système de bits de version BIP9 permet d'introduire des modifications rétrocompatibles aux règles de consensus Bitcoin, appelées soft forks. Les mineurs peuvent signaler leur soutien pour ces modifications, mais un processus spécifique doit être suivi pour leur activation. Ce mécanisme repose sur le respect d'un certain quota de blocs validés et suit un workflow rigoureux.

Qu'est-ce que les bits de version BIP9 ?

Le système de bits de version BIP9 est une méthode permettant d'introduire des modifications rétrocompatibles aux règles de consensus Bitcoin, connues sous le nom de soft fork. Grâce à ce système, les mineurs peuvent indiquer qu'ils sont capables de valider les nouvelles règles proposées. Il est également possible d'avoir jusqu’à 29 soft forks simultanément, ce qui offre une flexibilité considérable dans l’évolution du protocole Bitcoin.

Comment les bits de version sont-ils activés ?

Les bits de version n'exigent pas d'activation formelle ; ils servent simplement à signaler que les mineurs sont prêts à adopter un soft fork en configurant les bits dans le champ nVersion du bloc. Cette approche simplifie le processus tout en assurant que la communauté minière est prête pour la mise à jour.

Que sont les délais d’attente des soft forks ?

Chaque soft fork a une heure de début et un délai d’attente, définissant la période durant laquelle il peut être activé. Si le soft fork ne parvient pas à s'activer avant l'expiration du délai, il échoue automatiquement même s'il a été signalé comme accepté par certains blocs.

Quel est le workflow d'activation ?

Sous le système des bits de version, l’activation d’un soft fork suit un flux bien défini :

-> -> ->

-> ->

Le réseau Bitcoin ajuste la difficulté minière tous les 2016 blocs, moment où il vérifie combien parmi ces blocs ont soutenu la proposition. Si au moins 95 % des blocs signalent leur soutien, l’état passe alors à .

Une fois cet état atteint, la nouvelle règle sera appliquée après un nouvel ajustement difficile, consistant également en 2016 autres blocs.

Quelle est la version du bit ?

En l’absence de propositions actives pour des soft forks, les mineurs doivent configurer le champ versions du bloc sur 0x20000000 afin d’assurer une communication claire au sein du réseau.

Quand les mineurs doivent-ils placer les bits ?

Pour indiquer qu’ils soutiennent un soft fork spécifique, les mineurs doivent définir le(s) bit(s) concernés avec 0x20000000, et cela uniquement après l’heure officielle du début du soft fork. Ces bits doivent être désactivés si soit le changement s’active ou que l'état atteint celui de .

Par exemple :

Le soft fork « alice » utilise le bit 0 : soit 0x1 + 0x20000000.
Le soft fork « bob » utilise le bit 1 : soit 0x2 + 0x20000000.

Pour signifier deux changements simultanément : 0x20000003 (c’est-à-dire 0x1 + 0x2 + 0x20000000).

Il est crucial que si l’un des changements est activé avant l’autre ou échoue avant son activation, alors il faut désactiver immédiatement son bit correspondant.

En quoi diffère-t-il d’un soft fork ISM ?

L’ancien déclencheur ISM (IsSuperMajority()) active nouvelles règles lorsque 950 blocs sur 1000 supportent la nouvelle version. Contrairement aux systèmes basés sur BIP9 :

Un ISM rendra orphelins tous bloque précédents avec leur ancienne version après activation.
Avec BIP9, seulement ceux qui violent désormais ces nouvelles règles deviendront orphelins.
L’ISM évalue continuellement 1000 derniers blocs ; tandis que BIP9 examine chaque 2016 blocs lors des ajustements difficiles.
Les changements ISM ne possèdent pas cette notion expiratoire contrairement aux propositions sous BIP9 qui ne s'activent qu'entre heure start et expiration prévue.

Les mineurs doivent-ils se mettre à niveau ?

Non. Un changement sous forme souple via BIP9 ne sera actif que si au moins 95 % des mineurs montrent leur acceptation par leurs configurations respectives. Dans une situation où un changement atteint un état répertorié comme , ceux restants devraient envisager sérieusement une mise à niveau avant prochain reciblage (environ deux semaines). Ceux qui choisissent autrement risquent fortement produire des blocs invalides devenant ainsi orphelins faute validation appropriée.

Qui attribue les bits de version aux différentes propositions ?

Les propositions relatives aux différents changes se font via processus nommé BIP; celles actives sont documentées sur page dédiée listant affectations spécifiques.