Le BIP "Reduced Data Temporary Softfork" propose de désactiver temporairement diverses fonctionnalités de Bitcoin dans le consensus. J'ai examiné la blockchain pour quantifier l'impact potentiel, en identifiant les transactions historiques qui violent chacune de ces règles. 🧵↓

Règle n°1 : "Les nouveaux scripts de sortie scriptPubKeys dépassant 34 octets sont invalides, à moins que le premier opcode ne soit OP_RETURN, auquel cas jusqu'à 83 octets sont valides." Cela affecte toutes les sorties P2PK et P2MS, ainsi qu'un petit nombre de SPK non standard.

Règle n°2 : "OP_PUSHDATA* avec des charges utiles supérieures à 256 octets sont invalides, sauf pour le push redeemScript dans les scriptSigs BIP16." Je suppose que cela ne s'applique qu'aux pushes de données *exécutés*, donc j'ai exclu les pushes dans les enveloppes d'inscription taproot, dont il y en a très beaucoup.

Règle n°3 : "Dépenser des versions de témoin (ou Tapleaf) non définies (c'est-à-dire, ni Witness v0/BIP 141 ni Taproot/BIP 341) est invalide." Il y a un peu plus de 54 000 transactions avec des sorties de numéro de version non défini (principalement en utilisant de fausses sorties pour contourner la limite op_return).

Cependant, les BIPs 141 et 341 définissent des longueurs de programme de témoin spécifiques : - v0, longueur 20 (P2WPKH) - v0, longueur 32 (P2WSH) - v1, longueur 32 (P2TR) tel qu'écrit, le RDTS semble interdire toutes les autres longueurs de programme, y compris les ancres P2A (v1, longueur 2).

Règle n°4 : "Les témoins avec un annexe Taproot sont invalides." Jusqu'à présent, 11 transactions ont attaché un annexe aux dépenses taproot, principalement pour des jpegs.

Règle n°5 : "Les blocs de contrôle Taproot de plus de 257 octets (un arbre de Merkle avec 128 feuilles de script) sont invalides." Il y a environ 32k dépenses Taproot manifestement intégrant des données avec une profondeur de bloc de contrôle de plus de 100 (labitbus et similaires). Mais aussi une poignée de dépenses "légitimes" à une profondeur inférieure.

Règle n°6 : "Les Tapscripts incluant des opcodes OP_SUCCESS* n'importe où (même non exécutés) sont invalides." Il y a deux dépenses historiques de taproot incluant des opcodes OP_SUCCESS : la transaction de Burak, le "lightning-breaker", et cette démo ridicule d'OP_CAT.

Règle n°7 : "Les Tapscripts exécutant l'instruction OP_IF ou OP_NOTIF (quel que soit le résultat) sont invalides." Cela vise à désactiver l'"enveloppe d'inscription", qui a été utilisée par plus de 104 millions de transactions jusqu'à présent.

Cependant, RDTS va au-delà de la désactivation de l'enveloppe d'inscription, interdisant complètement OP_IF et OP_NOTIF. Environ 70 transactions non-inscription ont utilisé OP_IF dans des scripts taproot. Beaucoup sont des expériences de style bitvm, mais il existe également des exemples d'utilisations financières plus simples.

Par exemple, il y a quelques dépenses utilisant ce modèle de script "multisig en déclin", qui utilise plusieurs OP_IF.

Le plus inquiétant, c'est qu'il y a plusieurs dépenses d'un portefeuille utilisant ce modèle de script HTLC derrière un point NUMS bip341 (désactivant le chemin de clé) Le script utilise OP_IF pour choisir entre une branche nécessitant deux signatures et une préimage de hachage, ou une signature après un délai relatif.

Les partisans de RDTS ont rejeté les préoccupations concernant la confiscation liées à OP_IF et aux grands blocs de contrôle dans taproot en affirmant que les utilisateurs peuvent toujours dépenser via le keypath à la place. Cependant, environ 560k transactions ont dépensé des sorties taproot où le keypath était prouvablement désactivé.