Padronização e política

Curiosidade

1. Por que uma transação válida às vezes é rejeitada por uma carteira antes mesmo de chegar a um minerador?
2. O que acontece se uma contraparte usar um software diferente do seu, mas ambos estiverem “corretos”?
3. Como manter os opcodes não utilizados fora do caminho de retransmissão pode proteger futuras atualizações?

Explorar

1. As regras de consenso definem a validade; elas determinam o que pode aparecer em um bloco e ser aceito por todos os nós. A padronização é uma política local separada que determina quais transações um nó específico encaminha para seus pares e mantém em seu pool de memória. Uma transação pode ser perfeitamente válida segundo o consenso, mas não padrão de acordo com as políticas de encaminhamento padrão. Quando um usuário transmite tal transação, seu próprio nó pode descartá-la imediatamente, embora os mineradores possam tecnicamente incluí-la.
2. Os tipos de saída padrão são estritamente limitados para proteger os nodes contra ataques de negação de serviço e esgotamento de recursos. Estes incluem P2PKH, P2SH, P2WPKH, P2WSH, P2TR, scripts multisig simples (com até três chaves) e saídas de dados OP_RETURN de tamanho específico. Scripts que utilizam opcodes reservados ou desconhecidos, ou que excedem os limites de tamanho, não são transmitidos por padrão. Esse filtramento garante que o mempool permaneça gerenciável e impede que atores maliciosos inundem a rede com dados complexos e computacionalmente caros.
3. A política não é estática; ela evolui de acordo com a implementação em cada nó. Em 2025, os desenvolvedores do Bitcoin Core decidiram relaxar o limite padrão para o tamanho das saídas de dados OP_RETURN. Essa mudança gerou debate entre os operadores de nós, dos quais alguns se opuseram à expansão e passaram a usar softwares alternativos como o Bitcoin Knots para manter limites mais rígidos. Essa divergência ilustra que a padronização é um ajuste local: dois nós com versões ou ramificações diferentes podem transmitir subconjuntos diferentes de transações válidas sem violar o consenso.
4. Uma transação não padrão, mas válida, ainda pode ser confirmada se contornar completamente a rede de relé padrão. Os mineiros oferecem serviços de envio direto, permitindo que os usuários enviem transações diretamente em seus blocos, independentemente das políticas dos nós. Se uma carteira depende da rejeição de transações não padrão como medida de segurança — supondo que um script com aparência inválida nunca será propagado — ela enfrenta um risco: uma contraparte que utilize acesso direto aos mineiros pode confirmar essa transação. Isso gera uma diferença no comportamento, e não na verdade, podendo levar a movimentações ou perdas inesperadas de fundos.
5. A padronização atua como uma válvula de segurança para futuras atualizações do tipo “soft fork”. Ao impor regras mais rígidas agora — como tratar os opcodes NOP reservados para atualizações como não padrão durante o processo de transmissão — o protocolo garante uma transição suave quando as regras de consenso se tornarem mais estritas. Como as transações que utilizam esses opcodes reservados não são transmitidas ou mineradas por padrão, existem poucas ou nenhuma delas quando um “soft fork” dá significado a esses opcodes; assim, as novas regras não invalidam nada em que as pessoas confiavam, e é improvável que mineiros sem atualizações minem blocos rejeitados pelas novas regras.
6. Leia você mesmo as verificações de política: na fonte do Bitcoin Core, o arquivo policy/policy.cpp contém IsStandard e IsStandardTx, que listam os tipos de saída aceitos e os limites de tamanho; a série “Waiting for confirmation” da Bitcoin Optech explica o raciocínio por trás deles. Compare-os com as regras de consenso no código de validação e observe quão mais restritas são as regras de relay.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• Bitcoin Core source code, policy/policy.cpp
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023)
• Bitcoin Optech, 'Waiting for confirmation' series (2023)