BIPは、「データ削減一時的なソフトフォーク」で、コンセンサスでビットコインのさまざまな機能を一時的に無効にすることを提案しています。 私はブロックチェーンを調査し、これらの各ルールに違反する過去のトランザクションを特定することで、潜在的な影響を定量化しました。🧵↓

ルール #1: 「最初のオペコードがOP_RETURNされていない限り、34 バイトを超える新しい出力 scriptPubKey は無効であり、その場合、最大 83 バイトが有効です。」 これは、すべてのP2PKおよびP2MS出力、および少数の非標準SPKに影響します。

ルール #2: 「256 バイトを超えるペイロードを持つ OP_PUSHDATA* は無効です。BIP16 scriptSigs の redeemScript プッシュを除きます。」 これは*実行された*データプッシュにのみ当てはまると想定しているので、非常に多くのTaproot碑文エンベロープ内のプッシュを除外しました。

ルール #3: 「未定義のウィットネス (または Tapleaf) バージョン (つまり、Witness v0/BIP 141 でも Taproot/BIP 341 でもない) の使用は無効です。」 バージョン番号が未定義の出力を持つトランザクションが 54k 強あります (主にop_return制限を回避するために偽の出力を使用しています)。

ただし、BIP 141 および 341 は、特定の監視プログラムの長さを定義しています。 - v0、長さ 20 (P2WPKH) - v0、長さ 32 (P2WSH) - v1、長さ 32 (P2TR) 書かれているように、RDTSはP2Aアンカー(v1、長さ2)を含む他のすべてのプログラムの長さを禁止しているようです。

ルール #4: 「Taproot アネックスを含む証人スタックは無効です。」 これまでのところ、11件のトランザクションがtaprootの支出に付録を添付しており、そのほとんどがjpegのものです。

ルール #5: 「257 バイトを超える Taproot コントロール ブロック (128 個のスクリプト リーフを持つマークル ツリー) は無効です。」 ~32kの明らかにデータ埋め込みのタップルート支出があり、コントロールブロックの深さは100+です(labitbusなど)。 しかし、より低い深さでの「合法的な」支出も一握りです。

ルール #6: 「どこかに OP_SUCCESS* オペコードを含む Tapscript (実行されていない場合でも) は無効です。」 OP_SUCCESSオペコードを含む2つの歴史的なタップルート支出があります:Burakのライトニングブレーカートランザクションと、このばかげたOP_CATデモです

ルール #7: 「OP_IF または OP_NOTIF 命令を実行する Tapscript は (結果に関係なく) 無効です。」 これは、これまでに104m以上のトランザクションで使用されている「碑文エンベロープ」を無効にすることを目的としています。

ただし、RDTS は碑文封筒を無効にするだけでなく、OP_IFとOP_NOTIFを完全に禁止します。 約 70 件の非碑文トランザクションが Taproot スクリプトで OP_IF を使用しています。 多くは bitvm スタイルの実験ですが、より単純な金銭的利用の例もあります。

たとえば、この「減衰するマルチシグ」スクリプトテンプレートを使用して、複数のOP_IFsを使用する支出がいくつかあります

最も心配なのは、bip341 NUMSポイントの背後にこのHTLCスクリプトテンプレートを使用してウォレットから複数の支出があることです(キーパスを無効にします) このスクリプトはOP_IFを使用して、2 つの署名とハッシュ プリイメージを必要とするブランチか、相対タイムアウト後の 1 つの署名かを選択します。

RDTSの支持者は、ユーザーが代わりにキーパスを介していつでも使用できると主張することで、タップルートのOP_IFおよび大規模な制御ブロックに関連する没収の懸念を却下しました。 ただし、約 560k のトランザクションが、キーパスが無効であることが証明されたタップルート出力を費やしています。