O dia em que foram criados 184 bilhões de bitcoins

A publicação de Garzik era curta e objetiva. Mostrava o hash da transação e duas saídas gigantescas. Um registro posterior do printblock, na mesma discussão, indicava o valor exato: cada uma continha 92.233.720.368,54275808 BTC. O bloco também incluía uma transação coinbase separada, que pagava 50,51 BTC ao minerador. Ao lado da recompensa base habitual de cinquenta bitcoins, aquelas duas saídas pareciam absurdas: alguém acabara de criar mais de 184 bilhões de unidades.

Não se conhecia o autor da transação, nem havia uma explicação pública. A cadeia preservada mostra o que aconteceu, mas não quem explorou o erro ou com qual objetivo. Atribuir o ataque a um hacker específico seria acrescentar uma informação que as fontes não sustentam. O que sabemos é que a transação foi construída para explorar uma falha na validação.

A rede a aceitou porque o código antigo verificava os outputs individuais e, em seguida, sua soma. Cada um dos outputs gigantescos se encaixava no tipo numérico usado, mas, ao somar, ultrapassavam seu limite superior. O número transbordou para a área negativa, e a verificação subsequente concluiu erroneamente que não se criava um valor positivo não permitido.

Portanto, não se tratou de falsificação de assinatura, alteração de uma transação anterior ou tomada da maioria do hashrate. O atacante explorou a forma como a implementação específica lidava com números inteiros. A regra matemática "não emita mais do que entra" estava correta; o programa não a executou como as pessoas pretendiam devido ao transbordamento.

O bloco já fazia parte da cadeia seguida pela rede. Todos os nós com a versão defeituosa o consideravam válido, e outros mineradores podiam construir sobre ele. Por isso, divulgar o problema não bastava. A comunidade precisava agir antes que o histórico incorreto se espalhasse e que aquelas saídas enormes começassem a ser gastas.

O limite de 21 milhões é frequentemente descrito como uma lei imutável do Bitcoin. O incidente mostrou uma imagem mais precisa. O limite é um conjunto de regras de consenso que cada programa e cada nó completo deve executar sem erros. Se todas as versões de nós amplamente utilizadas compartilham a mesma implementação defeituosa, podem, por um tempo, aceitar um estado que contradiz a intenção.

O transbordamento de um número inteiro é um problema antigo de programação. Um registrador de computador não tem um alcance infinito; após ultrapassar o valor limite, a aritmética subsequente pode terminar em um lado completamente diferente do eixo numérico. Em um sistema contábil, tal detalhe é crucial. A soma deve ser verificada não apenas após o cálculo, mas durante ele, e cada quantia deve permanecer dentro do alcance permitido.

O Bitcoin Core de hoje, portanto, executa várias verificações separadas. O output não pode ser negativo, não pode exceder o estoque máximo de dinheiro, e a soma em andamento é re-verificada após cada adição. Essas linhas não foram criadas como uma precaução abstrata. Elas carregam a memória do evento em que uma proteção faltante permitiu que a rede registrasse uma transação economicamente impossível.

O erro também mostra a diferença entre a especificação e a expectativa social. Ninguém no fórum alegou seriamente que as moedas gigantescas são legítimas apenas porque o software antigo as aceitou. Os participantes concordaram que se tratava de uma violação da regra pretendida. Essa concordância, no entanto, precisava de um meio técnico: uma nova versão que rejeitasse o bloco defeituoso.

É aqui que o código e as pessoas se encontram. O código decide deterministicamente qual bloco o nó aceita. As pessoas decidem qual código instalar quando descobrem uma discrepância com as regras pretendidas. O incidente não foi um voto sobre uma nova emissão; foi uma corrida para restaurar a regra que a comunidade já considerava a base do sistema.

O transbordamento é traiçoeiro justamente porque a máquina não percebe a absurdidade que um ser humano reconhece de imediato. O processador opera com um número armazenado em um espaço limitado; se o cálculo ultrapassar seu limite, o resultado pode transbordar para outra parte da faixa. O código antigo verificava as saídas individuais, mas ao somar não mantinha a soma parcial dentro de limites seguros. A transação, portanto, passou por várias condições localmente razoáveis e, ainda assim, violou seu sentido global. A correção precisou ser concreta: não bastava escrever em um comentário que nunca haveria mais de 21 milhões de bitcoins. Cada nó precisava de uma regra que fosse capaz de efetivamente impor essa afirmação em cada cálculo.

Após o anúncio, apareceu no fórum a recomendação de parar de aceitar transações e não minerar temporariamente. Cada novo bloco sobre a transação defeituosa aumentaria a quantidade de trabalho que precisaria ser descartada. Na rede sem um interruptor central, Satoshi não podia parar a mineração. Ele apenas podia lançar uma correção e convencer os operadores a executá-la.

A versão 0.3.10 introduziu as verificações de quantia corretas e rejeitou o bloco 74.638. Os nós corrigidos retornaram ao último ponto válido comum e os mineradores começaram a construir uma ramificação alternativa sem a transação inflacionária. Por um tempo, as duas histórias competiram de acordo com o trabalho acumulado.

Satoshi anunciou subsequentemente que a boa cadeia ultrapassou a ruim. O software atualizado executou uma reorganização da cadeia e o bloco defeituoso desapareceu da história ativa. As transações da ramificação que não eram elas mesmas inválidas podiam retornar à fila e ser incluídas novamente mais tarde; os outputs gigantescos, no entanto, não podiam existir de acordo com as novas verificações.

Essa reparação teve um custo. Os mineradores na ramificação abandonada perderam recompensas, e os usuários tiveram que aceitar que algumas horas da história não continuariam. Em 2010, a rede era pequena e a coordenação foi rápida. A mesma intervenção em um ecossistema muito maior significaria mais participantes econômicos, variantes de software e disputas sobre onde exatamente a reparação se aplicava.

A rapidez da resposta costuma ser descrita como uma intervenção milagrosa de Satoshi. Na realidade, ela foi composta de passos observáveis: Garzik tornou o problema público, outras pessoas analisaram o estouro aritmético, os desenvolvedores prepararam a alteração, os operadores instalaram uma nova versão do cliente Bitcoin e os mineradores forneceram trabalho à ramificação correta. O autor podia propor a correção, mas a rede precisava adotá-la de fato.

Após a reparação, a quantidade de bitcoins válidos retornou ao quadro pretendido, e os bilhões defeituosos não podiam ser gastos na cadeia contínua. O incidente, portanto, não terminou em inflação permanente. No entanto, não é apenas uma curiosidade da versão beta. É um lembrete de que a certeza monetária não vem de um slogan, mas de um programa repetidamente verificado.

O Bitcoin é frequentemente comparado a sistemas em que a autoridade central altera a oferta por decisão. Aqui, no entanto, as pessoas não desaparecem. Os desenvolvedores escrevem implementações, os revisores procuram erros, os operadores escolhem versões, e os mineradores criam a ordem dos blocos. A diferença está em que a intervenção é pública, e cada nó pode rejeitar as regras com as quais não concorda.

O evento também explica a cautela com que o código de consenso é alterado hoje. Uma pequena otimização da aritmética pode ter consequências monetárias. Testes, mais controles de implementação e uma revisão lenta não são burocracia adicional; são defesas contra a repetição do momento em que alguns bits transformaram bilhões de um número impróprio em aparentemente válido.

Jeff Garzik não tornou a rede segura com um único post no fórum, mas mostrou a vantagem de um livro-razão público. Todos podiam ver o bloco estranho, recalculá-lo e verificar a reparação. O erro não estava escondido em uma base de dados interna do operador. Estava diante de toda a comunidade, junto com a prova de que os nós antigos o aceitaram.

O limite da oferta, portanto, sobreviveu ao incidente de uma maneira diferente do que sugere a palavra "imutável". Não porque o software não podia falhar, mas porque a falha era visível, havia uma regra compartilhada para a qual se podia retornar, e suficientes participantes executaram a reparação. A história dos 184 bilhões de bitcoins não é uma negação da oferta fixa. É a história do que a manutenção realmente exige.

O episódio também nos lembra que a natureza pública do código, por si só, não elimina o erro. O código aberto permitiu que as pessoas localizassem, comparassem e corrigissem o problema sem depender de um único fornecedor, mas o que foi decisivo foi a atenção de participantes específicos. Alguém precisou notar os números impossíveis, alguém precisou encontrar a condição defeituosa e os operadores precisaram adotar a atualização. A transparência criou a possibilidade de controle; foi apenas a ação que a transformou em defesa da rede. Por isso a história continua importante mesmo anos depois: a segurança do Bitcoin não reside na ideia de um programa original perfeito, mas na combinação de regras precisas, verificação independente e capacidade de reagir a um erro sem ocultá-lo.