Um Hard Fork é uma alteração do consenso em que o novo conjunto de validade não é um subconjunto do antigo. Um caso típico é uma ampliação: V(nova) permite um estado fora de V(antiga), por exemplo, um bloco maior tal como é visto pelo nó antigo ou uma construção que o software antigo considera inválida. A ativação não obriga os nós antigos a migrar; eles continuam a aplicar as suas próprias regras, pelo que a continuidade depende de coordenação voluntária.
Designemos por V(antiga) o conjunto de todos os blocos aceites pelas regras originais. Um Hard Fork ocorre quando o novo software aceita pelo menos um bloco fora desse conjunto, pelo que V(nova) não é um subconjunto de V(antiga). Muitas vezes trata-se de uma ampliação do conjunto de validade, mas o fator decisivo é a compatibilidade: se um bloco válido para um nó novo pode ser inválido para um nó antigo, o validador antigo não consegue seguir a nova cadeia sem alterar as suas regras. [Bitcoin Developer Guide — Consensus rule changes]
Um Full Node antigo não conhece nem reconhece a nova regra. Assim que os mineradores atualizados produzem um bloco que excede o limite antigo ou utiliza uma construção agora permitida, o nó antigo fica no último bloco que considera válido e rejeita a continuação desse ramo. Não é vencido por uma votação; executa de forma determinística um programa de consenso diferente. [Bitcoin Developer Guide — Consensus rule changes]
Uma data fixa, uma altura de bloco ou a sinalização dos mineradores podem coordenar quem adotou a atualização, mas não podem alterar o software de um nó que não a adotou. Se continuarem a existir participantes economicamente relevantes em cada um dos dois conjuntos de regras, ambas as cadeias podem prosseguir. O plano de ativação de um Hard Fork é, por isso, um plano de migração com risco de divisão. [Bitcoin Developer Guide — Consensus rule changes]
No ponto de divisão, ambos os ramos herdam o mesmo histórico anterior de UTXO. A partir daí, podem confirmar transações diferentes, utilizar limites diferentes e acumular valores diferentes de chainwork. Se ambos sobreviverem, o detentor tem normalmente um direito correspondente a moedas em ambas as cadeias, sujeito às regras posteriores, à proteção contra replay e ao suporte das carteiras. Já não se trata de um único registo contabilístico. [BCHN Technical Bulletin — shared history and 2017 split]
O Proof of Work seleciona entre ramos apenas depois de o nó considerar os blocos válidos. Um nó antigo nunca compara o chainwork de um ramo que contém um bloco inválido segundo as regras antigas com o da sua própria cadeia; primeiro descarta esse candidato. A afirmação de que «vence a cadeia com o maior hash rate» é, por isso, incompleta sem especificar as regras de validação. [Bitcoin Developer Guide — Consensus rule changes]
Depois da divisão, a utilização do mesmo formato de assinatura e de transação pode fazer com que uma única transação assinada seja válida em ambas as redes. Esse é o risco de replay. Um fork pode acrescentar proteção, um sighash diferente ou um formato de endereço diferente, mas são medidas separadas. O utilizador tem de distinguir as redes, os saldos, os endereços derivados e as regras das plataformas de negociação para creditar depósitos e processar levantamentos. [Bitcoin Cash upgrade specification — 2017 hard fork]
O Bitcoin Cash separou-se do Bitcoin à altura de bloco 478 559, em 1 de agosto de 2017. Adotou regras que permitiam blocos maiores do que os nós de Bitcoin aceitavam na altura e criou a sua própria cadeia, que continuou a funcionar. Os nós de Bitcoin rejeitaram os blocos válidos apenas em BCH, enquanto os nós de BCH seguiram o seu próprio histórico válido. É um exemplo de Hard Fork que criou uma rede separada, em vez de substituir o Bitcoin através de uma atualização na própria rede. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
Nem toda a divisão por incompatibilidade é um novo projeto monetário deliberado. Um erro de software pode provocar uma divergência temporária entre implementações, e uma versão de emergência pode fazer os participantes regressarem a um único conjunto de regras. A divisão do Bitcoin em março de 2013 resultou de diferenças de comportamento entre versões relacionadas com a base de dados e os limites. Foi resolvida pelo regresso coordenado dos mineradores ao ramo aceite pelos nós antigos da versão 0.7; não é equivalente à rede BCH mantida de forma duradoura. [BIP 50 — March 2013 chain fork post-mortem]
Um Soft Fork restringe o conjunto de validade de modo que V(nova) permaneça dentro de V(antiga); um nó antigo pode seguir os blocos compatíveis, mas não aplica a nova restrição. Um Hard Fork não tem esta compatibilidade unidirecional: um novo bloco válido pode ser inválido para um nó antigo. Mesmo um Soft Fork pode causar uma divisão se houver má coordenação, mas um Hard Fork exige migração pela sua própria definição. [Bitcoin Developer Guide — Consensus rule changes]
Os programadores podem publicar código, os mineradores deslocar hash rate, as empresas escolher um símbolo de negociação e regras de depósito, e os utilizadores escolher software. Nenhuma destas ações, por si só, reescreve as regras de consenso dos outros. Uma divisão duradoura pode persistir se um número suficiente de participantes independentes mantiver e valorizar voluntariamente ambos os conjuntos de regras; nem toda a alteração incompatível tem de criar duas redes permanentemente ativas. Chamar «atualização» a um dos ramos é uma designação social, não uma regra de consenso. [Bitcoin Developer Guide — Consensus rule changes]
O operador deve verificar a identificação da rede, a versão específica do software, os parâmetros de consenso, os pares, a ponta da cadeia, o hash do bloco no ponto do fork e as notas de versão ou os checkpoints correspondentes. Quando estão em causa fundos significativos, convém separar as carteiras e os procedimentos operacionais antes de gastar moedas resultantes do fork. Um explorador de blocos ou um símbolo de negociação ajuda, mas não substitui um nó próprio que valide as regras. [Bitcoin Core v29.0: getblockchaininfo]
Para ter uma visão mais completa, leia este verbete junto com Soft Fork, Regras de consenso, Full Node, Reorg, Guerra do tamanho dos blocos, UTXO. Também há referências a este verbete em Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Guerra do tamanho dos blocos.