O bitcoin entrou na janela final normal de 2.016 blocos do BIP-110 em 25 de julho, com suporte de mineiros de 0,89%. A proposta exige 1.109 blocos, ou 55%, para bloqueio normal, e sua fase obrigatória de bit de versão pode começar em agosto se o suporte permanecer abaixo desse limiar.
Jameson Lopp apresentou a Limpeza do Consenso, os convênios e a preparação quântica como a próxima agenda do bitcoin. Ele também ocupa dois lados dessa transição: Lopp se opõe ao BIP-110 e foi coautor do BIP-361, um plano preliminar para migração pós-quântica.
O BIP-110 oferece a esses debates uma referência de governança em tempo real, pois desenvolvedores, mineradores, operadores de nodes, exchanges, custodiantes e detentores fornecem cada um uma forma diferente de consentimento. As próximas propostas vinculam esse teste de coordenação à validação de blocos, custódia resistente a roubo e ao status de propriedade das moedas vulneráveis.
Bugs conhecidos entram na fila de atualização
Consensus Cleanup combina quatro correções de protocolo no BIP-54. Antoine Poinsot e Matt Corallo completaram a especificação em maio, e Bitcoin Inquisition tem aplicado as regras em seu signet experimental desde fevereiro.
O pacote aborda o ataque de timewarp, custos extremos de validação de blocos, uma ambiguidade da árvore de Merkle envolvendo transações de 64 bytes e verificações futuras de transações duplicadas.
A falha do timewarp permite que a maioria do poder de hash direcione a dificuldade de mineração em direção ao seu mínimo em 38 dias, antecipando a subvenção por meio da produção mais rápida de blocos e alterando os incentivos dos mineiros.
Uma fraqueza separada é que blocos especialmente criados podem levar vários minutos em hardware de alto desempenho e horas em máquinas mais fracas.
O BIP-54 limita as operações de assinatura por transação, reduzindo em um fator de 40 a carga máxima de validação. Ele também invalida uma forma de transação de 64 bytes que os mineradores tratam como não padrão desde 2019 e que o Bitcoin registrou pela última vez na cadeia em 2016.
Como esses reparos reforçam a validade do consenso, a revisão concentra-se em casos limite em toda a especificação, código de referência, vetores de teste e meses de uso no Signet. Um atraso prolongado deixaria quatro fraquezas documentadas no protocolo e aumentaria a probabilidade de que um ataque futuro comprima o cronograma de revisão.
A Limpeza do Consenso realiza um teste de manutenção no bitcoin com falhas definidas e remédios mensuráveis, permitindo a aprovação para demonstrar que a rede pode processar trabalho de protocolo defensivo por meio de revisão ordinária.
Atraso prolongado converteria fraquezas conhecidas em dívida técnica acumulada.
| Reparo do BIP-54 | Risco abordado | Impacto prático | Pergunta prospectiva |
|---|---|---|---|
| Correção do Timewarp | A maioria da potência de hash pode empurrar a dificuldade em direção ao mínimo | Poderia acelerar a produção de blocos e antecipar o subsídio | O bitcoin pode corrigir falhas conhecidas de incentivo antes que se tornem exploráveis? |
| Limites de custo de validação | Blocos criados podem levar minutos ou horas para serem validados | Enfraquece nós com recursos limitados e aumenta o risco de propagação | A rede prioriza a resiliência no pior caso antes que a pressão de ataque aumente? |
| Regra de transação de 64 bytes | Ambiguidade da árvore de Merkle devido ao formato de transação especial | Remove uma classe de ambiguidade histórica de consenso | A limpeza preventiva é mais fácil antes que o caso limite se torne weaponizado? |
| Limpeza de transações duplicadas | Preocupações futuras com validação do estilo BIP-0030 | Reduz o tratamento de exceções legadas | O bitcoin pode simplificar o consenso sem desencadear uma reação de coordenação? |
Covenants passam para teste ativo
A Bitcoin Inquisition ativou o OP_TEMPLATEHASH do BIP-446 em 27 de julho no bloco signet 314.928. O opcode permite que um Tapscript se comprometa com a transação exata que pode gastar uma saída, fornecendo às carteiras e sistemas de segunda camada uma primitiva de covenant.
Um cofre utiliza essa primitiva por meio de uma primeira transação que anuncia uma tentativa de retirada e cria um atraso durante o qual o proprietário pode redirecionar os fundos para um endereço mais seguro ou bloquear o pagamento do ladrão.
As construções atuais podem usar transações pré-assinadas e chaves de assinatura destruídas, um modelo operacional que se torna frágil com grandes saldos e longos períodos de armazenamento.
O BIP-448 propõe um pacote Tapscript de três opcodes que combina OP_TEMPLATEHASH com OP_CHECKSIGFROMSTACK e OP_INTERNALKEY.
Gregory Sanders, Antoine Poinsot e Steven Roose conectam o pacote a transações reassociáveis, canais de pagamento mais simples, designs de Lightning multipartidários, statechains e variantes do Ark.
Os revisores podem comparar uma ativação independente de TEMPLATEHASH, com sua superfície de revisão menor e ferramentas de cofre mais precoces, com o suporte mais amplo ao sistema de pagamento do BIP-448 e menor chance de outro soft fork.
Um período de teste mais longo mantém as regras de consenso atuais em vigor e aumenta a dependência de custódias ou construções pré-assinadas frágeis.
Para titulares, covenant policy determines quanto controle uma carteira pode codificar antes que os fundos saiam de um endereço.
Atrasos no Vault, caminhos de recuperação e modelos de gasto restrito podem fortalecer a autogestão e manter o controle fora das exchanges, ETFs ou custódios profissionais.
| Proposta | Variação principal | Caso de uso principal | Troca |
|---|---|---|---|
| BIP-446 / OP_TEMPLATEHASH | Vamos fazer o Tapscript comprometer-se com a transação de gasto | Cofres, caminhos de recuperação, gastos restritos | Superfície de análise menor, mas capacidade mais limitada |
| Pacote BIP-448 | Combina OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK e OP_INTERNALKEY | Canais de pagamento, Lightning multipartidário, statechains, variantes do Ark | Utilidade mais ampla, mas maior carga de revisão por consenso |
| Nenhuma ativação de acordo | Mantém as regras de consenso atuais | Vaults assinados previamente, controles de custódia, modelos de carteira existentes | Evita o risco de soft-fork, mas deixa as ferramentas de auto-custódia mais fracas |
A migração quântica define o prazo de propriedade
O BIP-361 coloca a maior tarefa de coordenação em um cronômetro de cinco anos. O rascunho interromperia a criação de novas saídas vulneráveis à computação quântica cerca de três anos após a ativação, e então os nodes apertariam a verificação para caminhos de gasto legados ECDSA e Schnorr por volta do quinto ano.
A Fase B exigiria um protocolo de resgate quântico seguro para gastos legados, embora o rascunho ainda não especifique um único design de resgate.
Esse cronograma exigiria exchanges, custódios, provedores de carteiras e detentores individuais a transferir fundos para um tipo de saída pós-quantum. Os proprietários que não migrarem até a Fase B precisarão atender às novas condições de resgate.
Ao incorporar garantias de propriedade no design de segurança, o BIP-361 visa impedir que um operador quântico transfira moedas expostas por meio de caminhos de gasto legados. Proprietários que perderem o prazo podem enfrentar maior dificuldade na recuperação, e qualquer mecanismo de resgate exigiria regras para design de prova, privacidade, controles de fraude e fundos inativos.
| Fase | Horário aproximado | Quais são as variações | Quem deve agir |
|---|---|---|---|
| Ativação | Ano 0 | O relógio de migração quântica começou | Desenvolvedores, operadores de node, provedores de carteira, exchanges, custodiantes |
| Fase A | Ao redor do ano 3 | Novas saídas vulneráveis à computação quântica deixariam de ser criadas | Carteiras, exchanges, processadores de pagamento, custodiantes |
| Fase B | Ao redor do ano 5 | A verificação legada ECDSA/Schnorr seria reforçada com regras de resgate quântico-seguras | Todos os titulares com saídas vulneráveis |
No cenário de alta, o processo BIP-110 produz padrões mais claros para a prontidão da rede. O BIP-54 recebe revisão concentrada, as propostas de covenant obtêm dados comparativos do signet e o planejamento quântico recebe uma janela de implementação de vários anos.
Carteiras ganham controles de roubo mais robustos, nodes ganham limites de validação mais rigorosos e custodiantes ganham tempo para inventariar saídas vulneráveis.
No cenário de baixa, a disputa de spam transforma cada soft fork em um conflito factional. O Consensus Cleanup permanece no signet, o trabalho com covenants se fragmenta entre pacotes de opcode concorrentes e a política pós-quantica aguarda uma ameaça criptográfica mais próxima.
O bitcoin leva bugs conhecidos, ferramentas de autogestão mais fracas e um cronograma de migração comprimido para o mesmo processo de governança.
A janela de agosto do BIP-110 criará um único registro da governança do bitcoin, e a Limpeza do Consenso, os covenant e o BIP-361 ampliarão esse registro para manutenção, custódia e sobrevivência criptográfica.
O caminho do bitcoin agora depende de identificar quais propostas de protocolo protegem suas funções principais e construir consenso antes que condições de emergência definam o cronograma.
A post Quatro falhas não corrigidas, um relógio quântico de 5 anos e um impasse dos mineiros estão empurrando o bitcoin para um momento crítico apareceu primeiro em CryptoSlate.