O ex-CEO da Mt. Gox, Mark Karpelès, propôs um pull request no Bitcoin Core para redirecionar cerca de 80.000 BTC roubados em 2011, avaliados hoje em aproximadamente US$ 5 bilhões. A sugestão, que exigiria um hard fork nas regras de consenso, foi fechada em menos de 17 horas pela comunidade, reacendendo o debate eterno: o Bitcoin deve ser imutável mesmo quando bilhões estão em jogo? Credores da Mt. Gox também rejeitaram a ideia, priorizando a integridade da rede.
A Proposta Técnica de Karpelès
Em detalhes, o código proposto por Karpelès, sob o handle MagicalTux no GitHub, consistia em menos de 60 linhas. Ele introduziria uma exceção nas regras de validação de transações para um endereço específico: 1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF, onde os 79.956 BTC repousam inativos desde o hack de 2011 na exchange Mt. Gox.
A mudança substituiria o hash da chave pública atual por outro controlado pelo trustee japonês da falência, permitindo gastar os coins após uma altura de bloco acordada. Isso configuraria um hard fork, pois tornaria válida uma transação previamente inválida, exigindo upgrade em todos os nós da rede Bitcoin. Karpelès definiu a ativação como “infinita”, dependendo de consenso comunitário.
A Mt. Gox, outrora 70% do volume de BTC, colapsou em 2014 após perder 850.000 BTC. Os coins em questão representam uma fração “congelada” pelo ladrão, nunca movimentada.
Por Que um Hard Fork Seria Problemático?
Do ponto de vista técnico, o Bitcoin opera como um banco de dados distribuído imutável, onde a posse é provada por chaves privadas via assinaturas ECDSA. Alterar isso para um caso específico viola o princípio de consenso neutro: as regras devem aplicar-se igualmente a todos os UTXOs (Unspent Transaction Outputs).
Precedentes existem, como o bug de overflow de 2010 (bloco 74638) ou o split de chain de 2013, mas eram correções de falhas que ameaçavam a rede inteira, não reatribuições seletivas. Um hard fork assim criaria um precedente subjetivo: vítimas de hacks em Bitfinex ou DeFi poderiam demandar o mesmo, politizando o protocolo e arriscando splits de chain.
Nodes rodando Bitcoin Core ou Knots rejeitariam tal mudança, pois compromete a imutabilidade histórica da blockchain, essencial para confiança em um sistema sem trusted third parties.
Reação Rápida da Comunidade e Governança Bitcoin
O pull request foi auto-fechado sem discussão formal, pois Karpelès pulou etapas: propostas devem iniciar na lista de desenvolvimento Bitcoin ou como BIP. Desenvolvedores como Matt Corallo sugeriram fóruns como Bitcointalk ou X para debate inicial.
No Bitcointalk, críticas foram veementes: “Bitcoin würde auf null sinken” (o valor do BTC cairia a zero), alertando para perda de reputação. Até credores Mt. Gox recusaram: “Absolutely not. Would break a key pillar of Bitcoin.” Eles valorizam a garantia de que “private keys equal ownership” mais que recuperação financeira.
Isso ilustra a governança do Bitcoin: descentralizada, rough consensus via desenvolvedores, miners, nodes e usuários econômicos. Não há CEO ou fundação central; mudanças radicais falham sem apoio amplo.
Lições para o Ecossistema Cripto
O episódio reforça “code is law”: o Bitcoin funciona como projetado, mesmo em casos simpáticos. Para recuperação, credores dependem de processos judiciais japoneses, não hacks no protocolo. Monitorar o endereço via explorers como Blockchain.com mostra inatividade persistente.
Para investidores, isso destaca riscos de custódia centralizada versus self-custody. A imutabilidade atrai instituições, mas testa resiliência ética em dilemas bilionários.
💰 Comece a investir em criptomoedas: Abra sua conta gratuita na Binance e acesse um dos maiores ecossistemas cripto do mundo.
📢 Este artigo contém links de afiliados. Ao se cadastrar através desses links, você ajuda a manter o blog sem custo adicional para você.
⚠️ Este conteúdo é informativo e não constitui recomendação de investimento. Faça sua própria pesquisa antes de tomar decisões financeiras.
