Mise à jour de Taproot : les utilisateurs de Bitcoin se concentrent sur le plan d'activation, la date reste à déterminer

De nombreux acteurs parmi les plus actifs de Bitcoin ont presque défini la méthode d'activation de Taproot, la plus grande mise à niveau du logiciel Bitcoin depuis des années.

Lors d'une réunion publique sur Internet Relay Chat (IRC) mardi, les développeurs, les mineurs, les professionnels et les passionnés de Bitcoin ont discuté des détails de la manière d'intégrer la mise à niveau de Taproot dans une mise à jour - et de la manière de l'activer une fois le code expédié.

Les plus actifs des quelque 200 participants au chat (principalement des développeurs, mais pas tous) semblaient d'accord sur la proposition d'amélioration de Bitcoin (BIP) qui servirait à activer Taproot. Pour préparer la BIP à son déploiement, ils ont également voté pour la fusion de deux « pull requests » (PR) sur GitHub décrivant les règles de la logique d'activation de Taproot dans le code source de Bitcoin lors de la mise à niveau.

Sur le même sujet : Comment la mise à niveau Taproot de Bitcoin améliorera la Technologies de la pile logicielle de Bitcoin

ONEun d'eux, RP n° 1021, inclut une mesure permettant aux utilisateurs de forcer l'activation de la mise à niveau si les mineurs ne la prennent pas en charge, tandis queRP n° 1020 Il recommande simplement ce forçage, mais ne l'active pas par défaut. Comme l'a indiqué Michael Folkson, animateur de la réunion et développeur Bitcoin CORE , la plupart des participants étant favorables à BIP 8 sans activation forcée, des discussions ultérieures permettront de déterminer une date de début d'activation et d'examiner plus en détail la nécessité d'un « jour de référence » pour forcer l'activation.

Pourquoi une journée du drapeau Taproot n'est (probablement) T nécessaire

Non pas que les mineurs bloquant la mise à niveau devraient être un problème pour Taproot, qui bénéficie d'un support de 91 % des mineurs,selon une enquête dirigé par le vice-président de Poolin, Alejandro De La Torre.

L'enquête fournit un retour d'information crucial de la part des mineurs pour l'organisation décentralisée de Bitcoin, qui ne peut coordonner unilatéralement les mises à jour comme le ferait un fournisseur de logiciels centralisé. Des mises à jour comme Taproot nécessitent une coordination minutieuse entre les mineurs, les utilisateurs de nœuds complets (ceux qui exécutent le code open source de Bitcoin) et les autres parties prenantes afin d'éviter tout problème (comme l'introduction d'un bug ou la division du réseau Bitcoin en deux versions incompatibles).

Étant donné que les mineurs n'ont montré aucune résistance à Taproot, la plupart des participants ont exprimé une préférence pour BIP8 (faux), le (faux) faisant référence à l'exclusion d'un « jour de drapeau » pour forcer l'activation via des nœuds complets si la mise à niveau échoue par manque d'activation du mineur.

Le BIP8, tel qu'il est actuellement conçu, donnerait aux mineurs de Bitcoin et aux opérateurs de nœuds complets un an pour adopter la mise à niveau, après quoi celle-ci serait « verrouillée » avec un support suffisant. Dans une version, BIP8 (faux), la mise à jour échouerait sans support suffisant. Dans une autre, BIP8 (vrai), un « jour de signalement » obligerait les mineurs à signaler la mise à niveau à l'expiration du délai d'activation s'ils ne l'avaient pas fait auparavant.

Sur le même sujet : Tous les principaux pools miniers prennent désormais en charge Taproot, la plus grande mise à niveau de Bitcoin depuis des années.

Note technique : Il existe plusieurs façons de mettre à niveau Bitcoin, la plus simple étant l'activation des mineurs, où les pools de minage se mettent à niveau et commencent à miner des blocs selon les nouvelles règles. À défaut, les opérateurs de nœuds peuvent effectuer une mise à niveau et choisir de rejeter les blocs des mineurs n'ayant pas signalé leur soutien à une mise à niveau. Il s'agit d'un « soft fork activé par l'utilisateur » (UASF). presquey utilisé pour activer SegWit, obligerait les mineurs récalcitrants à adopter la nouvelle mise à niveau.

« Complètement anecdotique mais je n'ai pas vun'importe lequel [c'est nous qui soulignons] opposition à Taproot », a déclaré ONE dans le chat, évoquant la nécessité d'un jour de drapeau. « Je pense que l'utilisation du plus petit dénominateur commun des paramètres d'activation (false) semble être le choix judicieux pour éviter toute division volontaire ou accidentelle de la chaîne en cas d' T de signalement de la part des mineurs. »

Qu’est-ce qui retarde ?

D'autres encore, comme Luke Dashjr, développeur prolifique de Bitcoin CORE , ne sont pas convaincus que l'inclusion d'un jour férié soit inutile. En fait, il s'agit d'une question de principe visant à démontrer que ce sont les opérateurs de nœuds qui décident des logiciels, et non les mineurs.

«T importe », a-t-il déclaré dans le chat en référence au support des mineurs. « Les mineurs ne décident pas des changements de protocole », a-t-il poursuivi, laissant entendre que ce sont les opérateurs de nœuds qui décident en choisissant le logiciel à exécuter. De plus, il a affirmé que BIP8 (false) « laisse les mineurs décider » du sort de la mise à niveau. Le moment venu, a-t-il précisé plus tard dans le chat, il configurera son nœud pour exécuter la version BIP8 (true), qui rejette les blocs non Taproot des mineurs.

« Le BIP8 avec [activation] obligatoire n'est pas une démonstration de force inutile », a déclaré hsjoberg, réitérant la conviction de Dashjr selon laquelle le choix de l'utilisateur d'un UASF est un contrôle et un équilibre nécessaires sur l'apathie des mineurs.

Sur le même sujet : UASF revisité : la révolte des utilisateurs de Bitcoin laissera-t-elle un héritage durable ?

Cependant, une démonstration de force pourrait introduire un risque inutile et créer un précédent fâcheux pour les futures délibérations de mise à niveau, en particulier lorsque les mineurs n'ont donné aux utilisateurs aucune raison d'être combatifs, d'où les arguments en faveur du BIP8 (faux).

« [BIP8 false] est plus sûr que [true], il vaut donc la peine de faire [false] en premier étant donné que nous savons que la puissance de hachage est déjà à environ 90 % pro-Taproot », a déclaré Chris Belcher, développeur de Bitcoin CORE et CoinSwap.

D'autres, comme Suredbits et le développeur de Bitcoin CORE, Ben Carman, ont souligné que vous pourriez configurer la mise à niveau ultérieurement lors de l'activation pour inclure le jour du drapeau si les mineurs ne parviennent pas à signaler, « rendant ainsi plus sûr et plus facile pour les utilisateurs d'appliquer l'UASF ».

À l'issue de la réunion, les participants ont convenu de fusionner les pull requests sur GitHub pour une activation non forcée (PR n° 1020) et une activation forcée (PR n° 1021). Ces deux règles étant présentes sur GitHub de Bitcoin Core, les règles d'activation forcée ne pouvaient être utilisées qu'en cas de nécessité.

Plus de délibération

Le scénario de division de chaîne décrit par willcl_ark est en fait le spectre que tout le monde souhaite éviter. La crainte est que BIP8 (true) nécessite 100 % du taux de hachage pour signaler la mise à niveau après la date limite d'activation de Taproot. Ainsi, si suffisamment d'utilisateurs empruntaient cette voie alors que d'autres utilisaient BIP8 (false) pour une activation non forcée (qui ne nécessite que 95 % du taux de hachage), les deux versions de code différentes pourraient créer deux historiques incompatibles du registre des transactions Bitcoin.

C'est pourquoi, si la signalisation forcée doit avoir lieu, il est préférable de le faire via le PR #1021 d'AJ Townes, qui « rend plus sûre l'option UASF qui est le scénario le plus « dangereux » », a écrit Carman dans le chat.

Pour l'instant, il semble que les personnes impliquées dans les discussions soient en faveur du BIP8 (faux) avec l'ajout d'un UASF via PR #1021 si nécessaire, mais des discussions plus approfondies sont nécessaires pour déterminer le calendrier exact de la période d'activation initiale (ou combien de temps les utilisateurs doivent mettre à niveau après la mise en ligne de la mise à jour), ainsi que la date d'activation à définir.

Ces « et si » et ces « quand » seront discutés, entre autres, lors d’une réunion le 16 février.