Bitcoin Magazine
Le Softfork Bitcoin qui a essayé de contrôler les « Données Indésirables » — Et pourquoi il échoue déjà
Ceci est un article invité de Brandon Black. Les opinions exprimées sont entièrement les siennes et ne reflètent pas nécessairement celles de BTC Inc. ou de Bitcoin Magazine.
Dans la petite bulle internet de Bitcoin X (anciennement Bitcoin Twitter ou Crypto Twitter), il y a eu beaucoup de bruit au cours de l'année dernière concernant la proposition de @dathon_ohm pour un Softfork Temporaire de Données Réduites, également connu sous le nom de BIP110. Sous-jacente à cette proposition est l'idée que certaines transactions Bitcoin ont violé les principes du réseau en incluant dans leurs scripts de verrouillage ou de déverrouillage des données qui peuvent être interprétées de manière une ou plusieurs façons supplémentaires en plus de leur interprétation de script Bitcoin classique. Selon les partisans du BIP110, réduire l'utilisation de ces transactions est une justification suffisante pour le softfork Bitcoin le plus confiscatoire à ce jour, sur une chronologie de déploiement qui est dramatiquement plus rapide que les deux softforks les plus récents, et avec un seuil de préparation à l'activation plus bas.
Bitcoin est un registre à accès ouvert et résistant à la censure auquel tout le monde peut écrire des entrées s'il est prêt à payer des frais suffisants pour convaincre les créateurs de modèles de blocs et les mineurs d'inclure leur transaction. La valeur fondamentale de Bitcoin par rapport à tous les autres systèmes de registre est cet accès ouvert mentionné précédemment. Sans cela, le registre de Bitcoin n'a pas plus de valeur que le tableau de score d'une salle de bowling. En raison de cet accès fondamentalement ouvert, nous savons tous que Bitcoin sera utilisé par ceux que nous détestons. Tout comme le principe de la liberté d'expression, qui est sans signification à moins qu'il ne s'applique à des discours que nous n'aimons pas, l'accès ouvert de Bitcoin serait sans signification s'il ne s'appliquait qu'aux transactions que vous ou moi approuvons. Je vais donc supposer que nous ne voulons pas être dans le métier d'inspecter comment les autres structurent leurs entrées de registre pas plus que nous ne voulons qu'ils inspectent nos entrées.
Les partisans de BIP110 pourraient dire : « Bien sûr, mais cela ne s'applique qu'à monétaire entrées ! Que dire de ces entrées non monétaires ?", mais la réalité est qu'il n'existe tout simplement pas de telle distinction. Chaque transaction effectuée sur Bitcoin est réalisée en satisfaisant les conditions d'un script de verrouillage pour faire une entrée dans le registre, ce qui consomme des pièces d'entrée et crée des pièces de sortie. Le fait qu'un script de transaction soit plus grand ou plus petit qu'un autre n'a aucune pertinence pour moi en tant qu'opérateur ou utilisateur de nœud Bitcoin. Tout d'abord, je ne regarde tout simplement pas les transactions des autres. Elles ne me concernent pas plus que les commandes des autres au café local. Deuxièmement, mon nœud ne fait aucune telle distinction. Les transactions sont soit valides, soit invalides, et elles sont soit coûteuses à valider (comme un gros multisig), soit peu coûteuses à valider (comme l'un de ces Ordinals ou OP_RETURNs).
On pourrait soutenir que le Bitcoin, comme l'or, serait un actif monétaire supérieur s'il ne pouvait pas également être considéré de d'autres manières. Imaginez si l'or ne pouvait pas être utilisé dans l'industrie ou la bijouterie ! Il se pourrait que cela le rende meilleur en tant que monnaie. Mais bien sûr, les mêmes propriétés qui font de l'or une bonne monnaie le rendent également désirable dans la bijouterie et l'industrie. Il en va de même pour le Bitcoin. Le simple fait que le Bitcoin permette à quiconque de faire une entrée s'ils sont prêts à payer les frais signifie que nous devons abandonner l'idée que nous pouvons contrôler comment ils vont considérer cette entrée. Peu importe les restrictions que nous imposons à la structure des entrées, il sera toujours possible de faire des entrées qui peuvent être interprétées de différentes manières par des logiciels non-Bitcoin. Ainsi, tant avec le Bitcoin qu'avec l'or, nous acceptons qu'un autre usage est inévitable. Dans le cas de l'or, cela entraîne des distorsions sur le marché lorsque la demande non monétaire augmente ou diminue. Dans le cas du Bitcoin, cela peut entraîner des périodes de frais de transaction plus élevés lorsque la demande pour son espace de bloc limité augmente.
Dans Bitcoin, nous avons deux avantages que l'or n'a pas. Tout d'abord, effectuer des transactions en Bitcoin qui peuvent être vues de manière alternative n'affecte pas le marché du Bitcoin lui-même. Contrairement à l'or, très peu de Bitcoin est alloué à ces usages. Deuxièmement, dans Bitcoin, nous avons un protocole qui est déjà conçu pour minimiser le coût pour le réseau de validation provenant de telles autres interprétations. Bitcoin limite à la fois la taille des blocs et le nombre de signatures qui peuvent être utilisées dans les transactions. Ce sont les plus grands coûts pour les nœuds de validation, et les limites du protocole à leur sujet sont en place depuis les tout débuts de Bitcoin, précisément pour prévenir les abus par toute utilisation à haute fréquence ou à fort volume du registre. Ces limites ont déjà stimulé des innovations telles que le Lightning Network, Ark, Spark, Cashu, et bien d'autres. Même le boom de la demande pour l'espace de bloc causé par ces entrées de registre « non monétaires » (oui, cela semble ridicule) a augmenté l'utilisation de ces solutions d'évolutivité, qui nécessitent moins d'entrées sur le registre principal.
Avec la justification du BIP110 ainsi explorée, et espérons-le montrée comme étant désespérément insuffisante, examinons le changement proposé lui-même. Le BIP110 restreint la taille des scripts de verrouillage, limite le nombre de scripts alternatifs dans taproot, rend l'annexe taproot invalide, supprime toutes les versions de témoins et de tapscript pouvant être mises à niveau, supprime tous les opcodes de tapscript pouvant être mis à niveau, et rend OP_IF et OP_NOTIF invalides dans tapscript. Toutes ces restrictions s'appliquent aux UTXOs créés pendant les 52414 blocs (environ 1 an) après son activation. Le BIP110 propose également un seuil de signalisation de préparation des mineurs de 55 % au lieu du seuil utilisé dans les précédents softforks signalés par les mineurs de 90 % ou plus. Si 55 % des blocs ne signalent pas leur préparation avant le bloc 961632, les nœuds appliquant le BIP110 traiteront les blocs non signalant la préparation comme invalides pour forcer le changement à se verrouiller d'ici le bloc 963648 et à s'activer d'ici le bloc 965664.
BIP110 serait la restriction la plus radicale du script Bitcoin depuis la désactivation bien connue de nombreux opcodes par Satoshi en réponse à une vulnérabilité critique (CVE-2010-5137) en 2010. Il propose une activation signalée par les mineurs avec un seuil incroyablement bas et une activation forcée par les nœuds après moins de 9 mois à partir de la date à laquelle le BIP a reçu un numéro. Tout cela est fait parce que (comme discuté ci-dessus) d'autres personnes voient certaines entrées de registre de manière que les partisans de BIP110 n'approuvent pas. Pire encore, les personnes qui utilisent de telles entrées de registre désapprouvées ont déjà mis à jour leur logiciel pour continuer à faire de telles entrées même si BIP110 devenait l'ensemble des règles de consensus de Bitcoin. C'était, bien sûr, un résultat prévisible (beaucoup d'entre nous l'ont explicitement prédit) car il est fondamentalement impossible de restreindre la façon dont d'autres personnes utilisent des logiciels externes pour analyser les entrées sur un registre public à accès ouvert.
En résumé, BIP110 est une proposition de faire quelque chose d'impossible (limiter comment les utilisateurs d'un grand livre à accès ouvert utilisent ce grand livre) en réponse à un problème qui est déjà entièrement résolu par les limites de protocole existantes de Bitcoin. Il propose de faire cette chose impossible dans un délai d'activation irresponsablement court, avec une révision de code incroyablement limitée, et indépendamment de savoir si le changement atteint un consensus de type écosystème. Heureusement, Bitcoin n'est pas un système aussi délicat qu'une fleur pour qu'une telle tentative imprudente de le modifier réussisse. Non seulement les mineurs ont catégoriquement rejeté BIP110, mais d'autres voix à travers le paysage des développeurs, investisseurs, influenceurs et entreprises se sont exprimées contre les changements. En août, cette attaque particulière contre les règles de consensus de Bitcoin aura rendu Bitcoin plus fort grâce à son échec, et le réseau continuera son rythme régulier de tic-tac, prochain bloc.
Source : BitcoinMagazine
