Uma reorganização é uma alteração local do chainstate, não uma alteração das regras de consenso do Bitcoin. Um Full Node aplica as suas próprias regras de validação e ativa o ramo com maior chainwork acumulado que cumpra essas regras. Se esse ramo divergir antes da ponta atual, o nó desfaz as alterações dos UTXO causadas pelos blocos desligados, aplica o ramo alternativo e reavalia as transações afetadas em relação ao mempool.
O Bitcoin Core não escolhe simplesmente o ramo mais alto ou mais popular. Durante a ativação, a cadeia candidata tem de cumprir as regras de consenso do nó; mais chainwork não torna válido um bloco inválido. FindMostWorkChain seleciona o candidato com mais trabalho que não se sabe ser inválido. Isto ainda não significa validação completa: são efetuadas verificações adicionais ao ligar os blocos em ActivateBestChain. Os ramos cuja invalidade é conhecida são excluídos. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
O ponto de bifurcação é o último bloco comum à cadeia atualmente ativa e ao ramo alternativo. A profundidade da reorganização é normalmente descrita pelo número de blocos da extremidade ativa que é necessário desligar para regressar a esse antepassado comum. Uma reorganização de um bloco substitui a ponta; uma reorganização mais profunda reverte vários blocos confirmados. A profundidade depende da perspetiva de cada nó. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
DisconnectTip e a lógica de validação subsequente desfazem os efeitos dos blocos desligados pela ordem inversa. Os UTXO gastos são restaurados e as saídas criadas pelo bloco removido deixam de estar confirmadas. É por isso que o Bitcoin Core guarda dados de reversão: tem de conseguir reconstruir o UTXO set exatamente no ponto de bifurcação. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Após a reversão, ConnectTip liga os blocos do ramo com maior chainwork pela ordem de avanço da cadeia. Cada transação é novamente validada face ao UTXO set reconstruído e às regras em vigor na altura de bloco correspondente. O resultado é um chainstate correspondente a uma única história concreta, e não uma mistura de transações dos dois ramos. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
As transações dos blocos desligados não têm necessariamente de desaparecer. O Bitcoin Core tenta devolver ao mempool as transações elegíveis que não sejam transações coinbase. Uma transação pode já estar no novo ramo; outra pode entrar em conflito, perder entradas, deixar de ser final ou não cumprir a política do mempool. A carteira tem, por isso, de contar com a possibilidade de uma reorganização anular uma confirmação. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
A transação coinbase é uma exceção: não regressa ao mempool depois de o bloco ser desligado. Segundo as regras de consenso, uma saída coinbase criada à altura h só pode ser gasta a partir do bloco h + 100. Quando a ponta está à altura h + 99, o bloco de origem tem 100 confirmações e a condição de maturidade permite incluir o gasto no bloco seguinte. Quando uma reorganização remove o bloco que contém a coinbase, a recompensa desse bloco desaparece do chainstate ativo. As transações subsequentes que dependiam da história removida também podem ser inválidas. [Bitcoin Core v29.0 — chain activation and mempool reconciliation] [Bitcoin Core v29.0 — coinbase maturity validation] [Bitcoin Core v29.0 — confirmation depth]
O número de confirmações inclui o bloco que contém a transação e todos os blocos seguintes na cadeia atualmente ativa de um determinado nó. Uma transação na ponta atual tem uma confirmação. Cada bloco adicional aumenta normalmente o trabalho necessário para substituir a história, mas nenhum número finito de confirmações cria uma irreversibilidade matematicamente absoluta. As plataformas de negociação e os comerciantes escolhem, por isso, o limiar em função do valor do pagamento e do seu modelo de risco. [Bitcoin Core v29.0 — confirmation depth] [Bitcoin whitepaper — Sections 5 and 11]
Uma reorganização curta pode surgir naturalmente quando dois mineradores encontram blocos concorrentes quase ao mesmo tempo e diferentes partes da rede seguem pontas diferentes durante algum tempo; o ramo com menos chainwork torna-se então obsoleto, ou stale. Um ataque de gasto duplo utiliza deliberadamente o mesmo mecanismo. O procedimento técnico de seleção da cadeia é o mesmo; a causa e o objetivo económico são diferentes. [Bitcoin Developer Guide — Block Chain] [Bitcoin whitepaper — Sections 5 and 11]
Uma reorganização ocorre dentro de um único conjunto de regras: o nó escolhe entre ramos que considera válidos. Um Hard Fork, pelo contrário, altera as regras de validade de modo que o software antigo e o novo podem discordar logo sobre se um bloco é válido. Assim, uma reorganização não é, por si só, uma alteração do consenso. [Bitcoin Developer Guide — Block Chain]
No Bitcoin Core v29.0, os passos são explícitos: FindMostWorkChain encontra o candidato com maior chainwork cuja invalidade não é conhecida; ActivateBestChainStep pode desligar a ponta atual; ConnectTip verifica e liga os blocos alternativos; e MaybeUpdateMempoolForReorg volta a verificar as transações dos blocos desligados. A ativação pode revelar que o candidato é inválido e prosseguir com a procura de outro ramo. Uma reorganização extensa exige o processamento de mais blocos desligados e ligados, pelo que pode prolongar o processamento de ActivateBestChain. [Bitcoin Core v29.0 — chain activation and mempool reconciliation]
Para ter uma visão mais completa, leia este verbete junto com Confirmação, Proof of Work, Stale Block, Gasto duplo, Full Node, UTXO. Também há referências a este verbete em Confirmação, Gasto duplo, Transação coinbase, Soft Fork.