Hard Fork to zmiana konsensusu, w której nowy zbiór poprawnych bloków nie jest podzbiorem starego. Typowym przypadkiem jest rozszerzenie: V(nowe) dopuszcza stan spoza V(stare), na przykład większy blok w postaci widocznej dla starego węzła lub konstrukcję, którą stare oprogramowanie uznaje za niepoprawną. Aktywacja nie zmusza starych węzłów do przejścia na nowe reguły; nadal egzekwują one własne zasady, więc ciągłość zależy od dobrowolnej koordynacji.
Oznaczmy przez V(stare) zbiór wszystkich bloków przyjmowanych według pierwotnych reguł. Hard Fork występuje wtedy, gdy nowe oprogramowanie przyjmuje co najmniej jeden blok spoza tego zbioru, a więc V(nowe) nie jest podzbiorem V(stare). Często oznacza to rozszerzenie zbioru poprawnych bloków, ale decydująca jest kompatybilność: jeśli blok poprawny dla nowego węzła może być niepoprawny dla starego, stary walidator nie może podążać za nowym łańcuchem bez zmiany reguł. [Bitcoin Developer Guide — Consensus rule changes]
Stary Full Node nie zna ani nie uznaje nowej reguły. Gdy tylko górnicy po aktualizacji utworzą blok przekraczający stary limit lub wykorzystujący nowo dozwoloną konstrukcję, stary węzeł zatrzyma się na ostatnim poprawnym dla niego bloku i odrzuci dalszy ciąg tej gałęzi. Nie zostaje przegłosowany; deterministycznie wykonuje inny program konsensusu. [Bitcoin Developer Guide — Consensus rule changes]
Ustalona data, wysokość bloku lub sygnalizacja górników mogą koordynować uczestników, którzy przyjęli aktualizację, ale nie mogą zmienić oprogramowania węzła, który jej nie przyjął. Jeśli przy każdym z dwóch zestawów reguł pozostaną uczestnicy o istotnym znaczeniu gospodarczym, oba łańcuchy mogą być kontynuowane. Plan aktywacji Hard Fork jest zatem planem migracji obarczonym ryzykiem podziału. [Bitcoin Developer Guide — Consensus rule changes]
W punkcie podziału obie gałęzie dziedziczą tę samą wcześniejszą historię UTXO. Następnie mogą potwierdzać różne transakcje, stosować różne limity i gromadzić różne wartości chainwork. Jeśli obie przetrwają, posiadacz ma zazwyczaj odpowiadające sobie uprawnienia do monet w obu łańcuchach, ograniczone późniejszymi regułami, ochroną przed replay i obsługą przez portfele. Nie jest to już jeden wspólny zapis księgowy. [BCHN Technical Bulletin — shared history and 2017 split]
Proof of Work służy do wyboru między gałęziami dopiero po uznaniu bloków przez węzeł za poprawne. Stary węzeł nigdy nie porównuje chainwork gałęzi zawierającej blok niepoprawny według starych reguł z chainwork własnego łańcucha; najpierw odrzuca takiego kandydata. Twierdzenie „wygra łańcuch o największym hash rate” jest zatem niepełne bez wskazania reguł walidacji. [Bitcoin Developer Guide — Consensus rule changes]
Ten sam format podpisu i transakcji może sprawić, że po podziale jedna podpisana transakcja będzie poprawna w obu sieciach. To ryzyko replay. Fork może dodać ochronę, inny sighash lub format adresu, ale są to odrębne środki. Użytkownik musi rozróżniać sieci, salda, wyprowadzone adresy oraz zasady giełd dotyczące księgowania wpłat i realizacji wypłat. [Bitcoin Cash upgrade specification — 2017 hard fork]
Bitcoin Cash oddzielił się od Bitcoina na wysokości bloku 478 559 dnia 1 sierpnia 2017 roku. Przyjął reguły dopuszczające większe bloki niż te, które akceptowały wówczas węzły Bitcoina, i stworzył własny, dalej działający łańcuch. Węzły Bitcoina odrzuciły bloki poprawne wyłącznie w BCH, a węzły BCH podążały za własną poprawną historią. Jest to przykład Hard Fork, który nie zastąpił Bitcoina przez aktualizację w dotychczasowej sieci, lecz stworzył oddzielną sieć. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
Nie każdy podział wynikający z niekompatybilności jest celowo tworzonym nowym projektem pieniężnym. Błąd oprogramowania może spowodować przejściową rozbieżność między implementacjami, a wydanie awaryjne może przywrócić uczestników do jednego zestawu reguł. Podział Bitcoina w marcu 2013 roku wynikał z różnego zachowania wersji związanego z bazą danych i limitami. Rozwiązano go przez skoordynowany powrót górników do gałęzi akceptowanej przez starsze węzły w wersji 0.7; nie jest to to samo co trwale utrzymywana sieć BCH. [BIP 50 — March 2013 chain fork post-mortem]
Soft Fork zawęża zbiór poprawnych bloków tak, aby V(nowe) pozostało wewnątrz V(stare); stary węzeł może podążać za kompatybilnymi blokami, ale nie egzekwuje nowego ograniczenia. Hard Fork nie ma tej jednokierunkowej kompatybilności: nowy poprawny blok może być niepoprawny dla starego węzła. Nawet Soft Fork może doprowadzić do podziału przy złej koordynacji, ale Hard Fork wymaga migracji już z samej definicji. [Bitcoin Developer Guide — Consensus rule changes]
Deweloperzy mogą opublikować kod, górnicy przenieść hash rate, firmy wybrać symbol giełdowy i zasady wpłat, a użytkownicy wybrać oprogramowanie. Żadne z tych działań samo w sobie nie nadpisuje reguł konsensusu innych uczestników. Trwały podział może się utrzymywać, jeśli wystarczająco wielu niezależnych uczestników dobrowolnie utrzymuje i ceni oba zestawy reguł; nie każda niekompatybilna zmiana musi stworzyć dwie stale działające sieci. Określenie jednej gałęzi jako „aktualizacji” jest kwestią społeczną, a nie regułą konsensusu. [Bitcoin Developer Guide — Consensus rule changes]
Operator powinien sprawdzić identyfikację sieci, konkretne wydanie oprogramowania, parametry konsensusu, połączone węzły, końcówkę łańcucha, hash bloku w miejscu podziału oraz odpowiednie informacje o wydaniu lub punkty kontrolne. Przy znacznych środkach warto rozdzielić portfele i procedury działania przed wydaniem monet pochodzących z podziału. Eksplorator bloków lub symbol giełdowy pomagają, ale nie zastępują własnego węzła przeprowadzającego walidację. [Bitcoin Core v29.0: getblockchaininfo]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Soft Fork, Reguły konsensusu, Full Node, Reorg, Wojna o rozmiar bloków, UTXO. Do tego hasła prowadzą również odsyłacze z Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Wojna o rozmiar bloków.