Bitcoin e Computação Quântica: o que o Whitepaper Não Previu e o que os Desenvolvedores Já Estão Construindo

O whitepaper de Satoshi Nakamoto, publicado em outubro de 2008 com nove páginas e cerca de 3.400 palavras, é um dos documentos mais densos da história da computação aplicada. Ele resolve o problema do double-spending sem coordenador central através de três componentes que se reforçam mutuamente: assinaturas digitais para prova de propriedade, uma função hash iterada como prova de trabalho e uma rede peer-to-peer para propagação e consenso.

O que o paper não discute — por boas razões em 2008 — é a hipótese de que um adversário poderia dispor de um modelo computacional radicalmente diferente do clássico. Dezoito anos depois, essa hipótese saiu do domínio teórico e entrou no domínio do planejamento de engenharia.

A Fundação Criptográfica do Bitcoin

Para entender a ameaça quântica com precisão, é necessário primeiro entender o que exatamente protege cada transação Bitcoin.

ECDSA e a curva secp256k1

Bitcoin usa o Elliptic Curve Digital Signature Algorithm (ECDSA) sobre a curva secp256k1, definida pela equação:

y² = x³ + 7  (mod p)

onde p = 2²⁵⁶ − 2³² − 2⁹ − 2⁸ − 2⁷ − 2⁶ − 2⁴ − 1, um primo de 256 bits escolhido por suas propriedades de performance em hardware de 64 bits.

A segurança do ECDSA repousa sobre a dificuldade computacional do Elliptic Curve Discrete Logarithm Problem (ECDLP): dado um ponto público Q = k·G na curva, onde G é o ponto gerador definido pela especificação secp256k1 e k é a chave privada (um inteiro de 256 bits), é computacionalmente inviável recuperar k a partir de Q em hardware clássico.

O melhor algoritmo clássico para ECDLP é o Pollard's rho, com complexidade O(√n) — aproximadamente 2¹²⁸ operações para secp256k1. Com hardware especializado operando a 10¹⁸ operações por segundo, isso levaria mais tempo que a idade do universo.

O pipeline de derivação de endereços

O endereço Bitcoin é o resultado de uma cadeia de transformações criptográficas sobre a chave pública:

privkey (256 bits, aleatório)
    ↓  multiplicação de ponto EC: Q = privkey · G
pubkey (512 bits não comprimido / 264 bits comprimido)
    ↓  SHA-256
    ↓  RIPEMD-160
pubkey hash (160 bits)
    ↓  Base58Check ou Bech32/Bech32m
endereço Bitcoin (P2PKH, P2WPKH, P2TR...)

A presença do double-hash SHA-256/RIPEMD-160 antes do endereço cria duas classes distintas de exposição quântica — e esta distinção é fundamental para entender qual porcentagem do supply está de fato em risco imediato.

Schnorr e Taproot

O BIP-340, ativo desde o soft fork Taproot em novembro de 2021, introduziu assinaturas Schnorr para outputs P2TR. Schnorr opera sobre a mesma curva secp256k1 e oferece linearidade (possibilitando MuSig e threshold signatures) e prova de segurança mais limpa. Do ponto de vista da resistência quântica, contudo, ECDSA e Schnorr sobre secp256k1 são igualmente vulneráveis ao algoritmo de Shor.

O Algoritmo de Shor e o ECDLP

O algoritmo de Shor, publicado por Peter Shor em 1994, resolve o problema da fatoração de inteiros e o problema do logaritmo discreto em tempo polinomial em um computador quântico. A redução do ECDLP ao logaritmo discreto em grupos cíclicos permite aplicar uma variante diretamente à curva secp256k1.

A complexidade de Shor para ECDLP-256 é O(n²) em número de operações quânticas — polinomial, não exponencial. Isso significa que um computador quântico suficientemente capaz pode, dado o ponto público Q, recuperar a chave privada k em tempo viável.

O paper do Google Quantum AI (março de 2026)

Em março de 2026, a equipe do Google Quantum AI publicou um whitepaper com estimativas revisadas dos recursos necessários para quebrar o ECDLP-256 sobre secp256k1. Os números anteriores situavam o requisito em dezenas de milhares de qubits lógicos. O paper de 2026 revisou essa estimativa para baixo em aproximadamente 20 vezes:

• ~1.175 qubits lógicos e aproximadamente 2,6 milhões de gates Toffoli na configuração mais eficiente em qubits
• Configuração alternativa: ~1.450 qubits lógicos e ~70 milhões de gates Toffoli (menor profundidade de circuito)
• Em termos de qubits físicos com taxas de erro atuais (supercondutores ~10⁻³): ~500.000 qubits físicos
• Tempo de execução estimado, com a primeira fase pré-computada: ~9 minutos

O detalhe dos 9 minutos é o que tornou o resultado criptograficamente relevante: é menor que o tempo médio de confirmação de um bloco Bitcoin (10 minutos). Isso significa que um atacante com um CRQC (Cryptographically Relevant Quantum Computer) poderia, em tese, derivar a chave privada de uma transação a partir da chave pública exposta no mempool — antes que ela seja incluída em um bloco.

É importante qualificar esse número. Os 500.000 qubits físicos referem-se a supercondutores com taxas de erro da geração atual. A relação entre qubits físicos e lógicos depende do código de correção de erros usado (Surface Code, Bacon-Shor, etc.) e das fidelidades reais de gate. O estado da arte em agosto de 2026 está na casa de alguns milhares de qubits físicos com coerência ainda insuficiente para correção de erros em escala. A distância entre a realidade e o requisito do ataque continua substancial — mas pela primeira vez tornou-se quantificável em uma unidade de engenharia plausível.

Um estudo de Monte Carlo publicado no arXiv (2606.14484) que integra escalonamento de hardware, redução de requisitos de recursos, lag de tolerância a falhas e surveys de especialistas produz uma distribuição bimodal: aproximadamente 1/6 de chance de um CRQC por 2035, ~30% por 2040, ~60% por 2050.

Taxonomia de Exposição: Nem Todo BTC é Igualmente Vulnerável

A distinção entre tipos de output é crítica para uma avaliação honesta do risco.

P2PK — risco imediato

Os blocos minerados nos primeiros anos do Bitcoin usam outputs P2PK, onde a chave pública está embarcada diretamente no scriptPubKey:

OP_PUSHDATA <pubkey_65_bytes> OP_CHECKSIG

A chave pública está exposta on-chain permanentemente, sem intermediação de hash. Um CRQC poderia derivar a chave privada a qualquer momento, sem precisar esperar uma transação em trânsito. Esta é a categoria de maior risco.

A análise do Patoshi pattern — o fingerprint de ExtraNonce identificado por Sergio Demian Lerner — indica aproximadamente 1,1 milhão de BTC em outputs P2PK que nunca se moveram, distribuídos em ~22.000 blocos precoces, presumivelmente do próprio Satoshi Nakamoto.

P2PKH e P2WPKH — risco em trânsito

O double-hash SHA-256/RIPEMD-160 protege parcialmente esses outputs. A chave pública só aparece on-chain no momento do gasto, no scriptSig ou witness. Antes do gasto, o que está on-chain é apenas o hash de 160 bits que não revela a chave pública.

O risco existe, mas é de natureza diferente: um atacante com CRQC precisaria monitorar o mempool, identificar transações com chave pública recém-exposta e derivar a chave privada em menos tempo que o próximo bloco (~10 minutos). A janela de ataque é estreita e requer execução em tempo real.

Endereços P2PKH/P2WPKH que nunca foram usados como inputs — portanto com chave pública nunca revelada — têm exposição quântica nula no modelo de ataque padrão.

P2TR — chave pública exposta by design

Taproot, paradoxalmente, expõe a chave pública on-chain de forma explícita. O scriptPubKey de um output P2TR é:

OP_1 <tweaked_pubkey_32_bytes>

A tweaked pubkey é derivada de P + t·G onde t = tagged_hash("TapTweak", P || merkle_root). Isso expõe a chave pública imediatamente na criação do output, mesmo antes de qualquer gasto. Outputs P2TR não-gastos têm a mesma categoria de risco que P2PK do ponto de vista quântico.

Números atuais

A análise da Glassnode de março de 2026 estima ~6,04 milhões de BTC (30,2% do supply emitido) em endereços com chave pública exposta on-chain. O Google Quantum AI whitepaper amplia essa estimativa para ~6,7 milhões quando incluídos outputs P2TR. Desses, aproximadamente 2,3 milhões de BTC são dormentes há mais de cinco anos — a categoria de risco mais concentrada, pois uma migração voluntária é improvável sem o portador das chaves.

O que os Desenvolvedores Já Estão Construindo

NIST FIPS 203, 204, 205 — o baseline pós-quântico

Em agosto de 2024, o NIST publicou os três primeiros padrões de criptografia pós-quântica após um processo de padronização iniciado em 2016:

• FIPS 203 (ML-KEM): derivado do CRYSTALS-Kyber. Mecanismo de encapsulamento de chave baseado em reticulados modulares (Module Learning With Errors — MLWE).
• FIPS 204 (ML-DSA): derivado do CRYSTALS-Dilithium. Esquema de assinatura digital baseado em reticulados, com chaves públicas de ~1.312 bytes e assinaturas de ~2.420 bytes no nível de segurança 2.
• FIPS 205 (SLH-DSA): derivado do SPHINCS+. Esquema baseado em hash trees (stateless), sem dependência de problemas algébricos estruturados. Chaves públicas pequenas (~32 bytes), mas assinaturas de ~8 KB (parâmetro rápido) a ~17 KB (parâmetro compacto).

A segurança de ML-DSA e SLH-DSA repousa em problemas distintos. ML-DSA depende da dureza do Module Learning With Errors (MLWE) — um problema reticular que não tem redução quântica conhecida eficiente. SLH-DSA depende exclusivamente de propriedades de funções hash (collision resistance, second-preimage resistance), tornando-a a opção mais conservadora do portfólio: mesmo que MLWE seja futuramente quebrado, SPHINCS+ permanece seguro enquanto SHA-256 permanecer resistente, o que é esperado mesmo com Grover reduzindo a segurança efetiva para ~128 bits.

BIP-360: Pay-to-Merkle-Root (P2MR)

O BIP-360, originalmente chamado Pay-to-Quantum-Resistant-Hash (P2QRH) e depois renomeado para Pay-to-Merkle-Root (P2MR), foi mesclado no repositório oficial de BIPs em fevereiro de 2026. Foi proposto por Hunter Beast (MARA Digital), Ethan Heilman e Isabel Foxen Duke.

A arquitetura define um novo tipo de output SegWit versão 2:

OP_2 <merkle_root_32_bytes>

A chave pública pós-quântica não aparece no output — apenas um Merkle root de 32 bytes que comita ao conjunto de chaves autorizadas. A chave pública real só é revelada no witness no momento do gasto, minimizando o tempo de exposição e mantendo o tamanho do output compatível com outputs Taproot existentes.

O witness de gasto inclui:

<pq_signature>  <pq_public_key>  <merkle_proof>

Onde merkle_proof prova que pq_public_key estava no conjunto comitado no output. Isso habilita também esquemas multisig heterogêneos — por exemplo, uma chave Dilithium e uma chave SPHINCS+ no mesmo endereço, com política M-de-N.

A BTQ Technologies implementou o BIP-360 completo em um testnet em março de 2026, incluindo cinco opcodes Dilithium habilitados em contexto tapscript e tooling CLI completo para criar e gastar transações P2MR. É a primeira implementação funcional de transações Bitcoin pós-quânticas em infraestrutura de teste real.

O trade-off de tamanho de witness é o problema de engenharia mais difícil. Uma assinatura Schnorr no Taproot ocupa 64 bytes. Uma assinatura ML-DSA (Dilithium-2) ocupa ~2.420 bytes — 38x maior. Uma assinatura SLH-DSA (SPHINCS+-SHA2-128s) ocupa ~8.000 bytes. Para referência, o limite atual de bloco Bitcoin permite ~4 MB de witness data (4 MWU). Uma transação com assinatura SPHINCS+ consome ~200x mais espaço de witness que uma assinatura Schnorr equivalente.

Isso não é um problema teórico — é um problema de throughput real. Com transações ~200x maiores, a capacidade da rede cai proporcionalmente, a menos que os limites de bloco sejam revisados em conjunto com a migração criptográfica.

BIP-361: sunset de ECDSA/Schnorr

O BIP-361, proposto como complemento ao BIP-360, define a mecânica de migração e um eventual sunset dos tipos de assinatura legados. A proposta é estruturada em três fases:

1. Fase 1 — Ativação do novo tipo de output P2MR em paralelo com os tipos existentes. Sem mudança compulsória. Wallets e aplicações podem adotar voluntariamente. 2. Fase 2 — Introdução de incentivos econômicos: taxas adicionais ou restrições de gasto para outputs legados, criando pressão de mercado para migração voluntária. 3. Fase 3 — Depois de uma janela definida (proposta de ~5 anos), outputs ECDSA/Schnorr legados que não migraram ficam sujeitos a congelamento de gasto pela rede.

O aspecto mais controverso é a fase 3. O debate técnico se divide em dois campos: aqueles que argumentam que o congelamento é necessário para proteger a rede de um ataque que drenaria UTXOs legados — incluindo potencialmente as moedas de Satoshi — e aqueles que argumentam que qualquer mecanismo que impeça o gasto de UTXOs viola as garantias fundamentais do protocolo. Esta é genuinamente uma das questões mais difíceis de governança técnica que o Bitcoin já enfrentou, não por complexidade criptográfica, mas por implicações filosóficas e de precedente.

Ethereum: STARKs como resposta sistêmica

A estratégia do Ethereum para pós-quantum é arquiteturalmente diferente da do Bitcoin. Em vez de adicionar novos tipos de assinatura ao protocolo existente, Vitalik Buterin e a Ethereum Foundation estão construindo um caminho onde STARKs (Scalable Transparent ARguments of Knowledge) se tornam o mecanismo primário de verificação de transações.

STARKs são sistemas de prova baseados em hash que não dependem de criptografia de curva elíptica nem de problemas algébricos estruturados. Sua segurança repousa na resistência de colisão das funções hash (SHA-256, Keccak, Poseidon), consideradas seguras contra Grover com uma expansão de 2x no parâmetro de segurança.

A Ethereum Foundation formou uma equipe dedicada de pós-quantum em janeiro de 2026, liderada por Thomas Coratger, e publicou um roadmap com alvo de 2029 para infraestrutura central do protocolo. Os quatro vetores técnicos são:

1. Assinaturas de validadores (camada de consenso)

A camada de consenso usa BLS12-381 para assinaturas de validadores — esquema baseado em pairings de curva elíptica, vulnerável ao algoritmo de Shor. A migração proposta é para esquemas baseados em hash ou reticulados.

2. Armazenamento de estado

O Merkle Patricia Trie usa keccak-256. Keccak é resistente a ataques quânticos com parâmetros atuais (output de 256 bits, segurança pós-quântica efetiva de ~128 bits contra Grover). Sem necessidade de migração imediata neste vetor.

3. Assinaturas de contas (EOAs)

O EIP-7702, ativo desde o fork Pectra, permite que EOAs deleguem autoridade para smart contract accounts. Isso cria um mecanismo de migração direto: o usuário pode delegar para um contrato que implementa verificação de assinatura pós-quântica, sem abandonar o endereço ou saldo existente. É o caminho de menor fricção para migrar as contas de usuários comuns.

4. Zero-knowledge proofs

Os zk-SNARKs usados em rollups dependem de pairings de curva elíptica (BN254, BLS12-381) no verificador. A migração para STARKs baseados em hash resolve simultaneamente o problema pós-quântico e o de trusted setup — STARKs são transparentes por design.

O roadmap "Lean Ethereum" de Vitalik Buterin, publicado em julho de 2026, eleva resistência quântica a prioridade de primeira classe ao lado de privacidade e escalabilidade, e enshrine STARKs recursivos como mecanismo de verificação primário do protocolo. O fork Hegotá é esperado como o último grande upgrade antes dessa fase de reconstrução.

Grover e as Funções Hash: Um Vetor Diferente

É comum ver computação quântica e Bitcoin discutidos exclusivamente no contexto de Shor e ECDSA. O algoritmo de Grover merece atenção separada — e um grau de alarme menor.

O algoritmo de Grover oferece uma speedup quadrático para buscas em espaços não estruturados. Aplicado a funções hash de 256 bits, ele reduz a segurança efetiva de 256 bits para ~128 bits — ainda confortavelmente acima de qualquer threshold de preocupação prática para SHA-256 e SHA3-256.

Para a Prova de Trabalho do Bitcoin especificamente, Grover ofereceria uma vantagem quadrática na mineração. Mas vantagem quadrática em mineração não quebra o protocolo — apenas representa um avanço em hardware de mineração, análogo (em termos de efeito no jogo econômico) a ASICs. A dificuldade de ajuste do protocolo reequilibra a rede. O consenso entre pesquisadores é que Grover não representa ameaça existencial à camada de consenso do Bitcoin.

O Problema da Governança é Mais Difícil que o Problema da Criptografia

O NIST já publicou os padrões. Os algoritmos estão definidos. As implementações estão em testnet. O que ainda não está resolvido é a coordenação.

No Bitcoin: o processo de ativação de soft forks requer consenso amplo entre mineradores, desenvolvedores e usuários. O histórico de controvérsias — SegWit e Taproot levaram anos de debate cada — sugere que uma mudança da magnitude de BIP-360/361 levará anos de negociação. O risco real não é que a criptografia falhe antes da solução estar pronta — é que a solução esteja pronta mas não ativada a tempo por falta de consenso.

No Ethereum: o modelo de governança mais centralizado em torno da Ethereum Foundation e dos client teams permite movimentos mais rápidos. O roadmap de 2029 é ambicioso mas credível, dado que Merge, Shanghai, Dencun e Pectra foram entregues em menos de quatro anos.

Nas aplicações: qualquer protocolo ou aplicação que usa bibliotecas cripto hoje — wallets HD derivando chaves via secp256k1, bridges assinando mensagens com ECDSA, oracles, multisigs — precisará de uma camada de migração. O inventário desse problema é imenso e distribuído por milhares de repositórios independentes.

Uma Perspectiva Calibrada

A análise honesta do estado atual leva a conclusões específicas:

O que é verdadeiro: O Google Quantum AI paper de março de 2026 reduziu materialmente as estimativas de recursos necessários para um ataque ao ECDLP-256. Isso não é alarmismo — é um resultado científico revisado por pares que a comunidade criptográfica levou a sério. O prazo de planejamento foi comprimido.

O que não é verdadeiro: Nenhum computador quântico existente em agosto de 2026 tem capacidade de executar o ataque. A fronteira atual está em alguns milhares de qubits físicos com coerência insuficiente para correção de erros em escala. Os 500.000 qubits físicos do modelo do Google são uma extrapolação de tendências, não uma realidade de laboratório.

O que é incerto: o timeline. O estudo Monte Carlo do arXiv (2606.14484) é o modelo mais rigoroso publicamente disponível, e sua distribuição bimodal — 1/6 de chance por 2035, 60% por 2050 — reflete genuína incerteza epistêmica sobre a velocidade de escalonamento de hardware quântico com correção de erros.

O que é imediato: o problema de coordenação. A janela de migração do Bitcoin — de um consensus change para adoção em massa — é medida em anos, não em meses. Começar em 2024 versus 2028 faz diferença real na probabilidade de completar a transição antes de um CRQC existir.

A trajetória técnica é clara: os algoritmos pós-quânticos existem, estão padronizados pelo NIST e as primeiras implementações estão em testnet. O Bitcoin e o Ethereum têm comunidades de desenvolvedores ativamente trabalhando no problema. O trabalho que resta — e é trabalho genuinamente difícil — é de engenharia de protocolo, coordenação de governança e migração de infraestrutura distribuída.

Nenhum desses problemas tem solução trivial. Nenhum deles é insolúvel.