Reorg je lokální změna chainstate, nikoli změna pravidel bitcoinového konsenzu. Full node nejprve ověří kandidátní bloky podle vlastních pravidel a teprve mezi platnými větvemi zvolí tu s nejvyšším kumulativním chainworkem. Pokud se liší pod současným tipem, vrátí UTXO změny odpojených bloků, aplikuje alternativní větev a znovu vyhodnotí dotčené transakce vůči mempoolu.
Bitcoin Core nevybírá jen nejvyšší nebo nejpopulárnější větev. Kandidátní řetězec musí nejprve splnit všechna konsenzuální pravidla, která uzel vynucuje. Funkce FindMostWorkChain a ActivateBestChain pracují pouze s platnými kandidáty; až potom rozhoduje kumulativní proof of work. Neplatný blok tedy nemůže vyhrát jen tím, že za ním stojí více hashratu.
Bod rozvětvení je poslední blok společný současnému aktivnímu řetězci a alternativní větvi. Hloubka reorgu se obvykle popisuje počtem bloků aktivního tipu, které je nutné odpojit k tomuto společnému předkovi. Jednoblokový reorg vymění tip, hlubší reorg vrací několik potvrzených bloků. Hloubka je relativní k pohledu konkrétního uzlu.
DisconnectTip a navazující validační logika vracejí účinky odpojených bloků v opačném pořadí. Utracená UTXO se obnoví a výstupy vytvořené odstraněným blokem přestanou být potvrzené. Proto Bitcoin Core uchovává undo data: musí umět rekonstruovat UTXO set přesně v bodě rozvětvení.
Po rollbacku ConnectTip připojuje bloky větve s vyšším chainworkem v dopředném pořadí. Každá transakce se znovu validuje vůči rekonstruovanému UTXO setu a pravidlům platným v dané výšce. Výsledkem je chainstate odpovídající jedné konkrétní historii, nikoli směs transakcí z obou větví.
Transakce z odpojených bloků nemusí zmizet. Bitcoin Core se způsobilé ne-coinbase transakce pokusí vrátit do mempoolu. Některá už může být v nové větvi, jiná může konfliktovat, ztratit vstupy, přestat být final nebo nesplnit mempool policy. Peněženka proto musí počítat s tím, že potvrzení může být reorganizací zrušeno.
Coinbase transakce je výjimka: do mempoolu se po odpojení nevrací a její výstupy lze podle konsenzu utratit až po 100 konfirmacích. Když reorg odstraní blok s coinbase, odměna tohoto bloku z aktivního chainstate zmizí. Neplatné mohou být i navazující transakce, které spoléhaly na odstraněnou historii.
Konfirmace počítá bloky nad transakcí v právě aktivním řetězci konkrétního uzlu. Každý další blok typicky zvyšuje práci potřebnou k nahrazení historie, ale žádný konečný počet konfirmací nevytváří matematicky absolutní finalitu. Burzy a obchodníci proto volí práh podle hodnoty platby a rizikového modelu.
Krátký reorg může vzniknout přirozeně, když dva těžaři téměř současně najdou konkurenční bloky a různé části sítě chvíli sledují různé tipy; větev s menším chainworkem pak zastará. Double-spend útok používá stejný mechanismus záměrně. Technický postup výběru řetězce je stejný, liší se příčina a ekonomický účel.
Reorg probíhá uvnitř jedné sady pravidel: uzel vybírá mezi větvemi, které považuje za platné. Hard fork naopak mění platnost tak, že starý a nový software se mohou neshodnout už na tom, zda je blok platný. Reorganizace tedy sama o sobě není změna konsenzu.
V Bitcoin Core jsou kroky explicitní: FindMostWorkChain najde nejlepší platnou větev, ActivateBestChainStep může odpojit současný tip, ConnectTip připojí alternativní bloky a MaybeUpdateMempoolForReorg znovu prověří transakce z odpojených bloků. Zdrojový kód výslovně upozorňuje, že rozsáhlý reorg může zpracování ActivateBestChain výrazně prodloužit.
Pro nejúplnější obraz čtěte toto heslo společně s Timechain, Potvrzení, Osiřelý blok, Proof of Work, Nakamotův konsensus, Bitcoin. Opačným směrem na něj odkazují také Potvrzení, Dvojí útrata, Coinbase transakce, Soft Fork.