“减少数据临时软分叉” BIP 提议暂时禁用共识中的各种 Bitcoin 功能。 我已经调查了区块链，以量化潜在影响，通过识别违反这些规则的历史交易。 🧵↓

规则 #1: "新的 output scriptPubKeys 超过 34 字节是无效的，除非第一个操作码是 OP_RETURN，在这种情况下，最多 83 字节是有效的。" 这影响所有 P2PK 和 P2MS 输出，以及少量非标准 SPK。

规则 #2: "OP_PUSHDATA* 的有效负载大于 256 字节是无效的，除了 BIP16 scriptSigs 中的 redeemScript 推送。" 我假设这仅适用于 *执行过的* 数据推送，因此我排除了 taproot 铭文信封中的推送，而这些信封有很多。

规则 #3: "支出未定义的见证（或 Tapleaf）版本（即，不是见证 v0/BIP 141 或 Taproot/BIP 341）是无效的。" 目前有超过 54,000 笔交易使用未定义版本号的输出（主要是使用虚假输出来绕过 op_return 限制）。

然而，BIPs 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 个明显的数据嵌入 Taproot 支出，控制块深度超过 100（labitbus 和类似的）。 但也有少量在较低深度的 "合法" 支出。

规则 #6: "在任何地方（即使未执行）包含 OP_SUCCESS* 操作码的 Tapscripts 是无效的。" 有两个历史的 taproot 支出包含 OP_SUCCESS 操作码：Burak 的 lightning-breaker 交易，以及这个愚蠢的 OP_CAT 演示

规则 #7: "执行 OP_IF 或 OP_NOTIF 指令的 Tapscripts（无论结果如何）都是无效的。" 这旨在禁用 "铭刻信封"，迄今为止已被超过 1.04 亿笔交易使用。

然而，RDTS 不仅仅是禁用铭文信封，还完全禁止 OP_IF 和 OP_NOTIF。 大约有 70 笔非铭文交易在 taproot 脚本中使用了 OP_IF。 许多是 bitvm 风格的实验，但也有一些更直接的金融用途的例子。

例如，有几个支出使用了这个 "衰减多重签名" 脚本模板，它使用了多个 OP_IF。

最令人担忧的是，使用这个 HTLC 脚本模板的一个钱包有多个支出，背后是一个 bip341 NUMS 点（禁用密钥路径） 该脚本使用 OP_IF 来选择一个分支，该分支需要两个签名和一个哈希预映像，或者在相对超时后只需要一个签名

RDTS 支持者对与 OP_IF 和 taproot 中的大控制块相关的没收担忧表示不屑，声称用户总是可以通过 keypath 进行支出。 然而，大约有 56 万笔交易支出了 taproot 输出，而 keypath 是可以证明被禁用的。