Hard Fork

Označme V(stará) všechny bloky přijímané původními pravidly. Hard fork nastane, když nový software přijme alespoň jeden blok mimo tuto množinu, takže V(nová) není podmnožinou V(stará). Často jde o rozšíření platnosti, ale rozhodující je kompatibilita: jestli může být blok platný pro nový uzel neplatný pro starý, starý validátor nemůže nový řetězec sledovat beze změny pravidel.

Starý full node nové pravidlo nezná ani neuznává. Jakmile upgradovaní těžaři vytvoří blok překračující starý limit nebo používající nově povolenou konstrukci, starý uzel skončí na posledním pro něj platném bloku a další větev odmítne. Není přehlasován; deterministicky provádí jiný konsenzuální program.

Pevné datum, výška bloku nebo signalizace těžařů mohou koordinovat ty, kteří upgrade přijali, ale nemohou změnit software uzlu, který jej nepřijal. Zůstanou-li ekonomicky významní účastníci na obou sadách pravidel, mohou pokračovat oba řetězce. Aktivační plán hard forku je proto migrační plán s rizikem splitu.

V bodě rozdělení obě větve zdědí stejnou předchozí historii UTXO. Potom mohou potvrzovat jiné transakce, používat jiné limity a nabírat jiný chainwork. Přežijí-li obě, držitel má typicky odpovídající nárok na mince na obou řetězcích, omezený pozdějšími pravidly, replay ochranou a podporou peněženek. Už nejde o jeden účetní záznam.

Proof of work vybírá mezi větvemi až poté, co uzel bloky uzná za platné. Starý uzel nikdy neporovnává chainwork větve obsahující starým pravidlům neplatný blok s vlastním řetězcem; takový kandidát nejdřív zahodí. Tvrzení 'vyhraje řetězec s největším hashratem' je proto neúplné bez uvedení pravidel validace.

Stejný formát podpisu a transakce může po rozdělení způsobit, že jedna podepsaná transakce je platná na obou sítích. To je replay riziko. Fork může přidat ochranu, jiný sighash nebo adresní formát, ale jde o samostatná opatření. Uživatel musí rozlišovat sítě, zůstatky, derivované adresy a pravidla burz pro připisování a výběry.

Bitcoin Cash se oddělil od Bitcoinu ve výšce 478 559 dne 1. srpna 2017. Přijal pravidla umožňující větší bloky, než tehdejší bitcoinové uzly přijímaly, a vytvořil vlastní pokračující řetězec. Bitcoinové uzly BCH-only bloky odmítly a BCH uzly sledovaly vlastní validní historii. Jde o příklad hard forku, který nevyměnil Bitcoin 'na místě', ale vytvořil samostatnou síť.

Ne každý nekompatibilní split je záměrný nový peněžní projekt. Chyba softwaru může způsobit dočasnou neshodu implementací a nouzová verze může účastníky vrátit na jednu sadu pravidel. Rozdělení Bitcoinu v březnu 2013 vzniklo rozdílným chováním verzí kolem databáze/limitů a bylo vyřešeno koordinovaným návratem těžařů na větev přijímanou staršími uzly 0.7; není totožné s trvale udržovaným BCH.

Soft fork množinu platnosti zužuje tak, aby V(nová) zůstala uvnitř V(stará); starý uzel může kompatibilní bloky sledovat, jen nevynucuje nové omezení. Hard fork tuto jednosměrnou kompatibilitu nemá: nový platný blok může být pro starý uzel neplatný. I soft fork může při špatné koordinaci splitnout, hard fork ale migraci vyžaduje přímo svou definicí.

Vývojáři mohou vydat kód, těžaři přesunout hash rate, firmy zvolit ticker a pravidla vkladů a uživatelé vybrat software. Nic z toho samo nepřepisuje konsenzus ostatních. Trvalý hard fork existuje, pokud dostatek nezávislých účastníků dobrovolně udržuje a oceňuje obě sady pravidel. Označení jedné větve za 'upgrade' je společenské, nikoli konsenzuální pravidlo.

Provozovatel má ověřit identifikaci sítě, konkrétní release, parametry konsenzu, peery, tip řetězce, hash bloku v místě forku a odpovídající release notes či checkpointy. U významných prostředků je vhodné oddělit peněženky a workflow před utrácením forked coins. Explorer nebo ticker pomáhají, ale nenahrazují vlastní validující uzel.