A proposta "Reduced Data Temporary Softfork" BIP sugere desativar temporariamente várias funcionalidades do Bitcoin no consenso. Eu examinei a blockchain para quantificar o impacto potencial, identificando transações históricas que violam cada uma dessas regras. 🧵↓

Regra #1: "Novos scripts de scriptPubKeys que excedam 34 bytes são inválidos, a menos que o primeiro opcode seja OP_RETURN, caso em que até 83 bytes são válidos." Isto afeta todos os outputs P2PK e P2MS, bem como um pequeno número de SPKs não padrão.

Regra #2: "OP_PUSHDATA* com payloads maiores que 256 bytes são inválidos, exceto para o push do redeemScript em scriptSigs BIP16." Assumo que isso se aplica apenas a *pushes* de dados *executados*, então excluí os pushes dentro de envelopes de inscrição taproot, dos quais há muitos.

Regra #3: "Gastar versões de testemunha indefinidas (ou Tapleaf) (ou seja, não Witness v0/BIP 141 nem Taproot/BIP 341) é inválido." Existem pouco mais de 54 mil transações com números de versão indefinidos (principalmente usando saídas falsas para contornar o limite op_return).

No entanto, os BIPs 141 e 341 definem comprimentos específicos para o programa de testemunhas: - v0, comprimento 20 (P2WPKH) - v0, comprimento 32 (P2WSH) - v1, comprimento 32 (P2TR) como está escrito, o RDTS parece proibir todos os outros comprimentos de programa, incluindo âncoras P2A (v1, comprimento 2).

Regra #4: "As pilhas de testemunhas com um anexo Taproot são inválidas." Até agora, 11 transações anexaram um anexo a gastos taproot, principalmente para jpegs.

Regra #5: "Os blocos de controlo Taproot maiores que 257 bytes (uma árvore merkle com 128 folhas de script) são inválidos." Existem ~32k gastos de taproot que claramente incorporam dados com profundidade do bloco de controlo de 100+ (labitbus e similares). Mas também há um punhado de gastos "legítimos" a profundidades mais baixas.

Regra #6: "Tapscripts incluindo opcodes OP_SUCCESS* em qualquer lugar (mesmo não executados) são inválidos." Existem dois gastos históricos de taproot incluindo opcodes OP_SUCCESS: a transação de Burak, o "lightning-breaker", e esta demonstração ridícula de OP_CAT.

Regra #7: "Tapscripts que executam a instrução OP_IF ou OP_NOTIF (independentemente do resultado) são inválidos." Isto visa desativar o "envelope de inscrição", que tem sido utilizado em mais de 104 milhões de transações até agora.

No entanto, o RDTS vai além de desativar o envelope de inscrição, banindo completamente o OP_IF e o OP_NOTIF. Cerca de 70 transações não inscritas usaram o OP_IF em scripts taproot. Muitas são experimentos no estilo bitvm, mas também há exemplos de usos financeiros mais diretos.

Por exemplo, existem alguns gastos usando este modelo de script "multisig em decadência", que utiliza múltiplos OP_IFs

O mais preocupante é que existem múltiplos gastos de uma carteira usando este modelo de script HTLC por trás de um ponto NUMS bip341 (desativando o caminho da chave) O script usa OP_IF para escolher entre um ramo que requer duas assinaturas e uma pré-imagem de hash, ou uma assinatura após um tempo limite relativo

Os defensores do RDTS descartaram as preocupações sobre a confiscação relacionadas ao OP_IF e grandes blocos de controle no taproot, afirmando que os usuários podem sempre gastar via o keypath. No entanto, cerca de 560 mil transações gastaram saídas de taproot onde o keypath foi comprovadamente desativado.