O BIP "Softfork temporário de dados reduzidos" propõe a desativação temporária de vários recursos do Bitcoin em consenso. Pesquisei o blockchain para quantificar o impacto potencial, identificando transações históricas que violam cada uma dessas regras. 🧵↓

Regra #1: "Novos scriptPubKeys de saída 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." Isso afeta todas as saídas P2PK e P2MS, bem como um pequeno número de SPKs não padrão.

Regra #2: "OP_PUSHDATA* com cargas maiores que 256 bytes são inválidas, exceto para o envio redeemScript em scriptSigs BIP16." Presumo que isso se aplique apenas a pushes de dados *executados*, então excluí pushes dentro de envelopes de inscrição taproot, dos quais existem 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 saídas de número de versão indefinidas (principalmente usando saídas falsas para contornar o limite de op_return).

No entanto, os BIPs 141 e 341 definem durações específicas do programa de testemunhas: - v0, comprimento 20 (P2WPKH) - v0, comprimento 32 (P2WSH) - v1, comprimento 32 (P2TR) conforme escrito, o RDTS parece proibir todos os outros comprimentos de programa, incluindo âncoras P2A (v1, comprimento 2).

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

Regra #5: "Blocos de controle de raiz de torneira maiores que 257 bytes (uma árvore merkle com 128 folhas de script) são inválidos." Existem ~ 32k obviamente gastos de raiz de torneira de incorporação de dados com profundidade de bloco de controle de 100+ (labitbus e similares). Mas também um punhado de gastos "legítimos" em 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 quebra-relâmpago de Burak e esta demonstração boba OP_CAT

Regra #7: "Tapscripts que executam a instrução OP_IF ou OP_NOTIF (independentemente do resultado) são inválidos." O objetivo é desativar o "envelope de inscrição", que foi usado por mais de 104 milhões de transações até agora.

No entanto, o RDTS vai além de desabilitar o envelope de inscrição, banindo OP_IF e OP_NOTIF completamente. Cerca de 70 transações sem inscrição usaram OP_IF em scripts taproot. Muitos são experimentos no estilo bitvm, mas também há exemplos de uso financeiro mais direto.

Por exemplo, há alguns gastos usando este modelo de script "multisig decadente", que usa vários OP_IFs

O mais preocupante é que existem vários gastos de uma carteira usando este modelo de script HTLC atrás de um ponto NUMS bip341 (desativando o caminho da chave) O script usa OP_IF para escolher entre uma ramificação que requer duas assinaturas e uma pré-imagem de hash ou uma assinatura após um tempo limite relativo

Os proponentes do RDTS rejeitaram as preocupações de confisco relacionadas à OP_IF e grandes blocos de controle no taproot, alegando que os usuários sempre podem gastar por meio do keypath. No entanto, cerca de 560 mil transações gastaram saídas taproot em que o keypath foi comprovadamente desabilitado.