A falha estava na implementação de uma regra de validação, não na criptografia nem no cronograma de emissão. Cada saída era positiva, mas a soma sofria um estouro e se tornava negativa. A diferença entre a entrada e esse total negativo parecia então uma taxa. A versão 0.3.10 acrescentou limites superiores às saídas individuais e ao total acumulado; após a reorganização para a ramificação corrigida, o bloco defeituoso saiu do histórico ativo.
Em 15 de agosto de 2010, o desenvolvedor Jeff Garzik chamou a atenção para o estranho bloco 74 638. A transação 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9 gastou uma única entrada de 0,50 BTC e criou duas saídas enormes. O registro printblock da época mostra 92 233 720 368,54275808 BTC em cada uma. O autor da transação que explorou a falha não foi identificado de forma confiável: o registro público documenta seus dados, não a identidade nem a motivação de quem a criou. [1]
O Bitcoin representava os valores como inteiros com sinal de 64 bits em satoshis. O valor inteiro de cada saída, também documentado em hexadecimal como 0x7ffffffffff85ee0, era positivo e ficava logo abaixo do máximo int64. A soma de 18 446 744 073 708 551 616 satoshis excedeu o intervalo e passou a −1 000 000 satoshis. A validação antiga aceitava esse total negativo ao compará-lo com a entrada. Era uma falha aritmética, não uma quebra das assinaturas. O primeiro registro JSON da discussão traz outros dígitos decimais finais; para o cálculo exato, usamos aqui o valor inteiro confirmado tanto pelo printblock quanto pela notação hexadecimal. [1]
O total negativo das saídas, −0,01 BTC, diante da entrada de 0,50 BTC produzia uma taxa aparente de 0,51 BTC. O minerador recebeu, portanto, 50,51 BTC na coinbase em vez da recompensa base de 50 BTC. Depois de subtrair a entrada gasta e incluir o excesso da coinbase, as duas saídas enormes aumentaram a oferta da ramificação defeituosa em exatamente 18 446 744 073 709 551 616 satoshis: 2^64 satoshis, ou 184 467 440 737,09551616 BTC. Esse número, portanto, não é apenas a soma das duas saídas. [2]
A comunidade reagiu publicamente e sob pressão. Lfm chamou o erro de grave, Gavin Andresen propôs verificar cada saída contra 21 milhões de BTC e Satoshi Nakamoto publicou uma forma mais abrangente: rejeitar uma saída negativa ou excessiva e o total acumulado excessivo após cada adição. Satoshi também pediu aos mineradores uma pausa temporária, para que uma nova ramificação válida pudesse alcançar e substituir mais rapidamente a defeituosa. [2]
Satoshi anunciou a versão 0.3.10 em 15 de agosto de 2010 às 23:48 no horário do fórum, cerca de cinco horas e quarenta minutos após o relato de Garzik. Os nós atualizados passaram a considerar inválidos a transação que explorou a falha e o bloco 74 638 e construíram sobre o último bloco válido comum. O anúncio da época informou depois que a ramificação boa superara a ruim, permitindo ao cliente atualizado se reorganizar automaticamente sem excluir manualmente arquivos da blockchain. [3]
Nenhum bloco antigo foi editado numa base de dados central. Havia dois históricos concorrentes: nós antigos aceitavam o bloco pelas regras originais, enquanto os corrigidos o rejeitavam e só aceitavam trabalho acima do ancestral válido. Quando a ramificação reparada acumulou mais Proof of Work, a rede a seguiu e o bloco inflacionário saiu do histórico ativo; foram decisivos a instalação das novas regras pelos usuários e mineradores e o trabalho posterior, não a ordem de um administrador. [3]
A proteção introduzida então continua visível no Bitcoin Core. CheckTransaction rejeita saída negativa, saída acima de MAX_MONEY e total acumulado fora de MoneyRange; verificar após cada adição impede que uma soma perigosa transborde antes da comparação. Um comentário no código cita explicitamente CVE-2010-5139, enquanto a verificação separada de entradas duplicadas lembra o incidente distinto CVE-2018-17144. [4]
O incidente mostra que o limite de 21 milhões não é uma constante mágica protegida apenas por hashing: regras precisas de validação e sua implementação correta o impõem. Uma auditoria deve cobrir intervalos individuais, adição segura, coinbase e taxas, ordem das verificações, vetores de teste limítrofes e concordância entre implementações independentes. A história também revela tanto a rapidez da comunidade inicial quanto sua grande dependência de poucos desenvolvedores, mineradores e coordenação manual. [5]
Para ter uma visão mais completa, leia este verbete junto com Bitcoin Core, Regras de consenso, Transação, UTXO, Reorg, Soft Fork.
01Já existiram 184 bilhões de BTC num Bitcoin válido?+
Eles existiram brevemente na ramificação defeituosa então minerada como resultado do bloco exploratório. Nós corrigidos rejeitaram essa ramificação e a válida a reorganizou, portanto as saídas enormes não integram a blockchain ativa nem o conjunto UTXO atuais. O incidente histórico, porém, está documentado pelo bloco e pela reação contemporânea.
02O incidente rompeu permanentemente o limite de 21 milhões?+
Não no histórico aceito hoje, pois as regras corrigidas rejeitaram o bloco defeituoso e suas saídas desapareceram na reorganização. O episódio mostrou que o limite depende da validação correta e do software realmente executado; uma frase na documentação não impõe a oferta por si só.