March 2013 Chain Split

Em 11 de março de 2013, um nó executando Bitcoin 0.8 minerou o bloco 225 430. A versão nova o aceitou, enquanto parte dos nós na versão 0.7.2 e anteriores o rejeitou; do mesmo bloco pai cresceram, portanto, uma ramificação com esse bloco e outra sem ele. A diferença não estava no hash nem no proof of work, mas em o software local considerar ou não o bloco válido. [2]

O gatilho não foi simplesmente o tamanho do bloco em bytes. O bloco continha uma quantidade de inputs de transação nunca vista, e os nós antigos esgotaram ao gravá-los o número padrão de locks do Berkeley DB. A quantidade necessária também dependia da disposição das páginas do banco de dados de cada nó; assim, um bloco menor, mas válido, podia falhar onde blocos de teste anteriores com tamanho máximo tinham passado. [1]

O Bitcoin 0.8 transferiu os índices de blocos e transações do Berkeley DB para o LevelDB, que não tinha o mesmo limite de locks. Inicialmente, cerca de 60 % do hashrate construía sobre a ramificação 0.8, mas os nós antigos não contavam seu trabalho porque rejeitavam o bloco inicial. A regra da cadeia mais pesada escolhe apenas entre históricos que o nó primeiro validou, portanto não conseguia resolver sozinha essa divergência. [1]

Pieter Wuille publicou o alerta de emergência e recomendou que comerciantes suspendessem o processamento de pagamentos. Após a discussão entre desenvolvedores e operadores, o BTCGuild, liderado por Michael Marsee, conhecido como Eleuthria, e o Slush Pool de Marek Palatinus voltaram ao Bitcoin 0.7. O objetivo não era declarar para sempre errada a ramificação tecnicamente mais nova, mas concentrar rapidamente o trabalho em um histórico que ambas as versões amplamente implantadas conseguiam validar. [3]

Quando a ramificação compatível assumiu a liderança em trabalho acumulado, os nós 0.8 se reorganizaram para ela e os blocos minerados apenas na ramificação 0.8 original se tornaram stale. O BIP 50 registra ao menos um double spend grande durante a divisão; segundo o post-mortem, foi um experimento, não uma tentativa de roubo. Ainda assim, o episódio mostrou por que exchanges e comerciantes pausam depósitos e aguardam mais confirmações quando a ponta da cadeia é incerta. [1]

O Bitcoin Core 0.8.1 foi lançado em 18 de março de 2013. Ele introduziu uma regra temporária de aceitação de blocos aplicada de 21 de março a 15 de maio, impedindo aceitar blocos que peers antigos não processavam, e adicionou um checkpoint embutido no bloco 225 430. O post-mortem também define uma estimativa de 10 000 locks, limite de mineração de 500 000 bytes e backports com limite de 537 000 locks do Berkeley DB. [4]

A compatibilidade temporária não era o estado final. Operadores de nós antigos tinham até 15 de maio para migrar para 0.8.1, um backport atualizado ou aumentar explicitamente o limite de locks; os mineradores não deveriam elevá-lo antes da data coordenada, para não criar novamente um bloco rejeitado pelo restante da rede. Em 16 de agosto de 2013, a rede aceitou o bloco 252 451 e deixou definitivamente para trás os nós sem correção. [5]

O incidente mostrou que consenso é mais do que a descrição do formato de bloco. Ele inclui o comportamento exato do código de validação, bibliotecas, transações de banco de dados, caminhos de erro e testes de limite. As medidas posteriores incluíram gerar transações de estresse na testnet, melhores alertas para serviços, monitoramento de ramificações laterais longas e coordenação mais cuidadosa de mudanças; a recuperação rápida também expôs a dependência da época em poucos desenvolvedores disponíveis e grandes pools. [1]