「減少數據臨時軟分叉」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 支出，主要是用於 jpegs。

規則 #5: "Taproot 控制區塊大於 257 位元組（具有 128 個腳本葉的梅克爾樹）是無效的。" 大約有 32k 明顯的數據嵌入 taproot 支出，控制區塊深度超過 100（labitbus 和類似的）。 但也有少數 "合法的" 支出在較低的深度。

規則 #6: "任何地方的 Tapscripts 包含 OP_SUCCESS* 操作碼（即使未執行）都是無效的。" 有兩個歷史性的 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 進行支出。 然而，大約有 560,000 筆交易已經支出了 taproot 輸出，其中 keypath 明顯被禁用。