Le développeur signale des risques majeurs dans la proposition de soft fork pour réduire les données de Bitcoin

Examen des données de transaction montre que RDTS pourrait bloquer des cas d’utilisation clés de Bitcoin

Une nouvelle proposition de soft fork conçue pour limiter le stockage excessif de données sur la blockchain Bitcoin suscite des critiques vives ces derniers temps. Mercredi, l’analyste indépendant et développeur de mempool.space, Mononaut, a publié une évaluation exposant les dommages collatéraux potentiels que le jeu de règles pourrait causer.

La proposition, connue sous le nom de softfork temporaire à données réduites (RDTS), introduit une série de restrictions au niveau du consensus destinées à réduire les transactions lourdes en données — un effort que les développeurs déclarent nécessaire suite à la mise à jour Bitcoin Core v30 qui a supprimé les limites sur les données OP_RETURN.

Le RDTS s’appliquerait pendant environ un an s’il est activé, limitant les scriptPubKeys à 34 octets, plafonnant les sorties OP_RETURN à 83 octets, restreignant les blocs de contrôle Taproot, interdisant les versions de témoin non définies, et désactivant des catégories entières de logique Tapscript. Les partisans du BIP soutiennent que les mesures agissent comme un frein d’urgence contre les téléchargements arbitraires de données qui pourraient exposer les opérateurs de nœuds à des responsabilités légales si du matériel illégal était intégré dans la chaîne.

L’évaluation de Mononaut, cependant, quantifie les retombées pratiques de ces restrictions en examinant l’activité historique de la blockchain pour voir quelles transactions réelles auraient violé les règles proposées. Ses conclusions suggèrent une perturbation significative. Sous la limite de taille des scriptPubKey seule, toutes les sorties pay-to-public-key (P2PK) et multisig (P2MS) seraient invalides. Cette restriction affecte également un petit nombre de sorties non standard dans les transactions passées.

L’une des règles les plus radicales—invalidant les opérations OP_PUSHDATA avec des charges utiles supérieures à 256 octets—n’affecterait pas les enveloppes d’inscription, supposant que seules les poussées exécutées sont qualifiées. Mais Mononaut a souligné que les versions de témoin non définies affecteraient plus de 54 000 transactions historiques, dont beaucoup ont utilisé des sorties non conventionnelles pour contourner les plafonds de données OP_RETURN. Comme les longueurs de version de témoin sont strictement définies dans les BIPs 141 et 341, la proposition telle qu’elle est rédigée bloquerait même certains formats modernes valides tels que les ancres P2A.

A lire aussi: Les développeurs de Bitcoin Core fusionnent des changements de politique controversés : un fork est-il à l’horizon ?

Mononaut a détaillé que le RDTS invalide également des piles de témoins contenant une annexe Taproot. Bien que rare, le développeur de mempool.space note qu’au moins 11 transactions ont utilisé une annexe à des fins lourdes en données. Une catégorie plus significative, a souligné Mononaut, est celle des grands blocs de contrôle Taproot : environ 32 000 dépenses passées incluent des blocs de contrôle de profondeur 100+ souvent utilisés pour l’intégration de données, mais même certaines expérimentations non liées aux données s’appuient sur des configurations plus petites et légitimes qui seraient désactivées. Une adresse active dépense régulièrement à une profondeur de bloc de contrôle de 11, ce qui serait rejeté sous RDTS.

Les articles de ligne les plus stricts de la proposition—interdisant OP_SUCCESS* et tout Tapscript exécutant OP_IF ou OP_NOTIF—vont bien au-delà des enveloppes d’inscription. Mononaut met en lumière deux transactions OP_SUCCESS historiques, y compris la transaction interférant avec le lightning de Burak, et environ 70 dépenses Taproot basées sur OP_IF non lié à l’inscription. Plusieurs de celles-ci sont des primitives financières, y compris des modèles multisig dégressifs et des designs de contrats à verrouillage de temps par hachage (HTLC). Certaines proviennent de portefeuilles qui ont intentionnellement désactivé leur chemin de clé, laissant la dépense par chemin de script comme le seul moyen de déplacer les fonds.

Les défenseurs du soft fork temporaire soutiennent que le RDTS est une mesure protectrice à court terme conçue pour préserver l’utilité monétaire de Bitcoin, prévenir les risques légaux et réduire la charge des nœuds en limitant le stockage des données. Les critiques rétorquent que des restrictions larges sur le comportement Tapscript risquent d’introduire une censure de facto, de désactiver des types de transactions valides et de casser les applications existantes.

Le débat reflète des disputes antérieures sur la croissance des données portées par les inscriptions, reflétant des désaccords plus profonds sur la question de savoir si Bitcoin doit rester strictement monétaire ou continuer à accueillir des utilisations expérimentales. Alors que la proposition reste à l’état de brouillon, la discussion est en cours parmi les développeurs, les chercheurs et les participants de l’écosystème.

FAQ ❓

• Qu’est-ce que le RDTS ?
  Une proposition de soft fork temporaire qui restreint plusieurs fonctionnalités de script et de données de Bitcoin.
• Pourquoi le RDTS est-il débattu ?
  Les partisans veulent limiter les abus de données, tandis que les critiques disent qu’il désactive des transactions valides.
• Qu’a trouvé Mononaut ?
  Son analyse montre que de nombreuses transactions historiques échoueraient sous les règles du RDTS.
• Combien de temps le RDTS durerait-il ?
  La proposition prévoit une fenêtre d’activation d’un an si elle est adoptée.