Bitcoin Core : : Softfork CSV


Il y a un soft fork en cours des règles de consensus Bitcoin. Bien que tout semble bien se dérouler, cet article contient des informations importantes et des listes de contrôle pour les mineurs et les exploitants de piscines qui ne doivent pas être ignorées.

En cas de doute.

TL; DR

  • Vérifiez que tous vos nœuds ont été mis à niveau vers Bitcoin Core 0.12.1 ou un logiciel compatible. Cela doit se produire avant le bloc #419328. Notez que si votre ou vos clients GBT implémentent correctement le protocole, vous devrez patcher le PR #8176 (patch) ou utiliser Bitcoin Knots qui l’inclut déjà.

    Bitcoin Core : : Softfork CSV

  • Si vous codez en dur la version du bloc, veuillez désactiver le bit 0 du champ de version avant le bloc 419328, ou de préférence arrêtez de le coder en dur et laissez bitcoind le faire automatiquement.

  • Si vous devez utiliser une autre valeur nLockTime, vous devez suivre attentivement les instructions.

  • État du soft fork CSV

    Le soft fork « CSV » a atteint le seuil « verrouillé » requis pour procéder à l’activation. Sur les 2016 blocs de #415296 à #417311, 1946 (96,53%) ont signalé la préparation pour le softfork BIP68, BIP112 et BIP113 (« CSV »). À partir du bloc #417312 (2016-06-21 05 :18 :58 UTC), le softfork CSV est maintenant dans une période de grâce « verrouillée » pendant environ 2 semaines jusqu’au bloc 419327. Après cela, les nouveaux BIP68, BIP112 et Les règles BIP113 seront activées et appliquées par le réseau. Il a dépassé le «point de non-retour» et est irréversible sans un retour en arrière massif de la blockchain.

    Pour tous les mineurs

    Pendant la période de grâce, tous les mineurs doivent passer à Bitcoin Core 0.12.1 ou à toute implémentation prenant en charge le softfork CSV. En pratique, au moment de la rédaction, Bitcoin Core et Knots 0.12.1 sont les seules versions qui prennent en charge le softfork CSV. Les mineurs doivent revérifier pour s’assurer que tous les nœuds de minage et les nœuds de sauvegarde ont été mis à niveau. Ne pas le faire peut entraîner la génération de blocs invalides ou faire en sorte que vos nœuds s’appuient sur des blocs invalides, entraînant des fourches de chaîne et des pertes monétaires pour les mineurs concernés et les utilisateurs généraux de Bitcoin.

    Pour les mineurs qui ont manuellement codé en dur la version du bloc

    Par défaut, Bitcoin Core définit et désactive automatiquement les bits de version selon les besoins, cependant.

    Si un mineur a par inadvertance des nœuds qui ne prennent pas en charge les règles indiquées par la version du bloc, cela pourrait entraîner la production de blocs invalides, et cela pourrait amener le mineur à suivre et à construire sur une chaîne invalide. En bref, en n’utilisant pas la valeur par défaut fournie par bitcoind, cela augmente le risque de découplage de la signalisation des règles de blocage et de l’application des règles de blocage.

    Contrairement au softfork IsSuperMajority utilisé dans BIP33/66/65, dans le système de softfork BIP9, aucun bloc ne sera orphelin en raison d’un numéro de version erroné (tant que la version est >= 4, ce qui est requis par BIP65). Par conséquent, les mineurs ne devraient pas être incités à coder en dur la version en bloc, ce qui augmenterait inutilement le fardeau de la maintenance et les risques d’erreur humaine.

    Cependant, si vous définissez manuellement la version de blocage par rapport à cette recommandation, vous DEVEZ prendre des mesures spécifiques. Maintenant que la période de grâce du « point de non-retour » a été atteinte pour CSV, vous devez désactiver le bit de version CSV, le bit 0. Cela signifie que si vous signaliez 0x20000001, vous devriez signaler 0x20000000. Cela DOIT être changé avant le bloc #419328 ou vous déclencherez des messages « softfork inconnu » dans les journaux de tous les nœuds conformes à BIP9. veuillez consulter la FAQ sur les bits de version.

    ce qui sera très perturbateur.

    Pour les mineurs qui autorisent Bitcoin à définir automatiquement la version du bloc, aucune autre action n’est requise. Veuillez noter qu’il continuera à générer des blocs avec la version 0x20000001 jusqu’au bloc #419328, auquel cas il désactivera automatiquement le bit 0.

    Concernant le champ nLockTime de la transaction de génération

    Ceci est rare, mais les mineurs utilisant le champ nLockTime doivent porter une attention particulière en raison de l’activation de BIP113.

    Si un mineur interfère avec le nLockTime de la transaction de génération de quelque manière que ce soit, il doit s’assurer que la valeur, si elle est interprétée comme un horodatage UNIX (c’est-à-dire >= 500000000), doit être inférieure à la valeur d’horodatage médiane des 11 derniers blocs, sauf si la nSequence de la transaction de génération est exactement 0xffffffff.

    veuillez utiliser une valeur de 0.

    Le non-respect des instructions ci-dessus peut entraîner la génération de blocs invalides, provoquant une fourche de chaîne et une perte monétaire pour les mineurs concernés et les utilisateurs généraux de Bitcoin.