Предложение BIP "Временный мягкий форк с уменьшенными данными" предлагает временно отключить различные функции Bitcoin в консенсусе. Я проанализировал блокчейн, чтобы количественно оценить потенциальное воздействие, выявив исторические транзакции, которые нарушают каждое из этих правил. 🧵↓

Правило №1: "Новые выходные scriptPubKeys, превышающие 34 байта, недействительны, если первый опкод не OP_RETURN, в этом случае допустимо до 83 байт." Это затрагивает все P2PK и P2MS выходы, а также небольшое количество нестандартных SPK.

Правило #2: "OP_PUSHDATA* с полезными нагрузками больше 256 байт недопустимы, за исключением push redeemScript в скриптах BIP16." Я предполагаю, что это относится только к *выполненным* данным, поэтому я исключил pushes внутри конвертов с надписями taproot, которых очень много.

Правило №3: "Расходование неопределенных версий свидетелей (или Tapleaf) (т.е. не Witness v0/BIP 141 и не Taproot/BIP 341) недопустимо." Существует чуть более 54 тыс. транзакций с неопределенным номером версии выходов (в основном с использованием поддельных выходов для обхода ограничения op_return).

Однако BIP 141 и 341 определяют конкретные длины программ свидетелей: - v0, длина 20 (P2WPKH) - v0, длина 32 (P2WSH) - v1, длина 32 (P2TR) как написано, RDTS, похоже, запрещает все другие длины программ, включая P2A якоря (v1, длина 2).

Правило №4: "Стеки свидетелей с annex Taproot недействительны." На данный момент 11 транзакций прикрепили annex к расходам Taproot, в основном для jpeg.

Правило #5: "Контрольные блоки Taproot размером более 257 байт (меркле-дерево с 128 скриптовыми листьями) недействительны." Существует около 32 тысяч очевидно содержащих данные трат Taproot с глубиной контрольного блока более 100 (labitbus и подобные). Но также есть несколько "законных" трат с меньшей глубиной.

Правило #6: "Tapscripts, включающие коды операций OP_SUCCESS* в любом месте (даже неисполненные), являются недействительными." Существует два исторических расходования taproot, включая коды операций OP_SUCCESS: транзакция Burak's lightning-breaker и этот глупый демо OP_CAT.

Правило №7: "Tapscripts, выполняющие инструкцию OP_IF или OP_NOTIF (независимо от результата), недействительны." Это направлено на отключение "конверта для инскрипции", который был использован более чем в 104 миллионах транзакций на данный момент.

Однако RDTS идет дальше, чем просто отключение конверта для записи, полностью запрещая OP_IF и OP_NOTIF. Около 70 транзакций без записи использовали OP_IF в скриптах taproot. Многие из них являются экспериментами в стиле bitvm, но также есть примеры более простого финансового использования.

Например, есть несколько расходов, использующих этот шаблон скрипта "разлагающегося мультиподписного" (decaying multisig), который использует несколько OP_IF.

Наиболее тревожным является то, что из кошелька с использованием этого шаблона скрипта HTLC происходит несколько трат, связанных с точкой bip341 NUMS (отключение ключевого пути) Скрипт использует OP_IF для выбора между ветвью, требующей две подписи и хэш-преобразованием, или одной подписью после относительного таймаута.

Сторонники RDTS отвергли опасения по поводу конфискации, касающиеся OP_IF и крупных контрольных блоков в taproot, утверждая, что пользователи всегда могут тратить через ключевой путь. Тем не менее, около 560 тыс. транзакций потратили выходы taproot, где ключевой путь был доказуемо отключен.