FAQ sur les bits de version pour les mineurs


Le système de bits de version BIP9 est un moyen d’introduire des modifications de règles rétrocompatibles dans les règles de consensus Bitcoin, connues sous le nom de soft fork.

Les bits de version permettent aux mineurs de signaler qu’ils peuvent valider les règles du soft fork. Il permet également de proposer jusqu’à 29 fourches souples simultanément.

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

les bits de version ne nécessitent pas d’activation, c’est simplement un moyen pour les mineurs de signaler qu’ils sont prêts pour un soft fork en définissant des bits dans le champ nVersion d’en-tête de bloc.

FAQ sur les bits de version pour les mineurs

Qu’est-ce qu’un soft fork timeout ?

Les soft forks ont une heure de début et un délai d’attente pendant lesquels la proposition est active. Le soft fork ne peut être activé qu’entre l’heure de début et le timeout. Si le soft fork n’est pas activé par le délai d’attente, la proposition de soft fork échoue et ne s’activera pas même si elle est signalée.

Qu’est-ce que le workflow d’activation ?

Sous version bits, une proposition de soft fork passe par un workflow  :

  • -> ->>

ou alors

  • ->>

Le réseau Bitcoin recible les difficultés de minage tous les 2016 blocs ; à ce moment, les bits de version examineront la fenêtre des blocs 2016 précédents pour voir combien de blocs signalent pour un soft fork donné. Si 95 % des blocs signalent qu’ils sont prêts pour le soft fork, l’état passe de pour.

Après les règles s’activeront après un autre retarget de difficulté, c’est-à-dire 2016 blocs supplémentaires. Le logiciel Nodes avertira qu’une mise à niveau est en attente.

Quelle est la version?

Lorsqu’aucun soft fork n’est signalé, les mineurs doivent définir le champ de version du bloc sur 0x20000000.

Quand les mineurs doivent-ils définir des bits ?

Pour signaler qu’ils sont prêts pour le(s) soft fork(s), les mineurs doivent définir le(s) bit(s) de version pertinent(s) avec 0x20000000. Cela ne devrait être fait qu’après l’heure de début du soft fork.

Les bits doivent être désactivés si le soft fork s’active ou atteint Etat.

Par example :

« alice » soft fork utilise le bit 0, c’est-à-dire 0x1 + 0x20000000

0 0 1 0 0 … 0 0 0 0 0 0 0 0 0 1

« bob » soft fork utilise bit, 1, c’est-à-dire 0x2 + 0x20000000

0 0 1 0 0 … 0 0 0 0 0 0 0 0 1 0

Pour signaler les deux fourches souples à la fois,

0 0 1 0 0 … 0 0 0 0 0 0 0 0 1 1

  • notez que si l’un est activé avant l’autre, vous devez désactiver le bit correspondant et continuer à signaler l’autre. SI l’un ne s’active pas et que le délai d’attente expire, vous devez également désactiver le bit

En quoi diffère-t-il d’une fourche souple ISM ?

IsSuperMajority () ou ISM en abrégé, est un déclencheur soft fork hérité qui active de nouvelles règles une fois que 950 blocs sur 1000 sont extraits, ce qui signale la nouvelle version du bloc.

  • Un soft fork IsSuperMajority() rendra orphelins tous les blocs avec la version précédente après l’activation. Par exemple, si la version actuelle est 4 et que le prochain soft fork introduit des blocs de version 5, une fois l’activation atteinte (950/1000 blocs), les nœuds rejetteront tous les blocs de version 4.

  • Une fois qu’un soft fork de bits de version atteint l’activation, les nœuds commenceront simplement à appliquer les nouvelles règles et ne rendront PAS orphelin un bloc non-signalant à moins qu’il ne viole les nouvelles règles.

  • ISM() regarde les 1000 blocs précédents sur une base continue ; les bits de version examinent le bloc précédent de 2016 une fois à chaque fois que la difficulté de minage se recible.

  • Les soft forks ISM() n’expirent pas. Les soft forks des bits de version ne peuvent s’activer qu’entre l’heure de début et le délai d’attente.

  • Les mineurs doivent-ils se mettre à niveau ?

    Non. Une fourche souple BIP9 ne s’activera que si 95% des mineurs signalent qu’ils sont prêts. Si une fourche souple atteint état, où la grande majorité des mineurs sont prêts pour le changement, les mineurs restants devraient mettre à niveau avant le prochain retarget de difficulté (environ 2 semaines).

    Les mineurs non mis à niveau risquent de produire des blocs invalides qui seraient orphelins s’ils ne sont pas en mesure de valider les règles nouvellement activées.

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

    Les fourches souples sont proposées via le processus BIP. Les propositions de soft fork BIP9 actives sont répertoriées sur la page des affectations

    Lectures complémentaires