Nešlo o spor nad novým pravidlem, ale o skrytou závislost validace na databázové implementaci: novější LevelDB zvládla blok s neobvykle mnoha vstupy, kdežto předchozí verze vyčerpaly výchozí počet Berkeley DB zámků; těžaři proto koordinovaně obnovili kompatibilní větev a následné vydání 0.8.1 připravilo řízený přechod.
Dne 11. března 2013 vytěžil uzel s Bitcoinem 0.8 blok 225 430. Nová verze jej přijala, zatímco část uzlů ve verzi 0.7.2 a starší jej odmítla; od stejného rodiče proto vznikla větev s tímto blokem a větev bez něj. Rozdíl nebyl v hashi nebo proof of work samotném, ale v tom, zda místní software blok vůbec považoval za platný. [2]
Spouštěčem nebyla prostě velikost bloku v bajtech. Blok obsahoval dosud neobvykle mnoho transakčních vstupů a staré uzly při jejich zápisu vyčerpaly výchozí počet zámků Berkeley DB. Počet potřebných zámků navíc závisel na rozložení databázových stránek konkrétního uzlu, takže i menší, jinak platný blok mohl selhat tam, kde dřívější maximálně velké testovací bloky prošly. [1]
Bitcoin 0.8 přesunul index bloků a transakcí z Berkeley DB do LevelDB, která stejný limit zámků neměla. Přibližně 60 % hashratu zpočátku stavělo na větvi 0.8, ale starší uzly její práci nepočítaly, protože výchozí blok odmítly. Pravidlo nejtěžšího řetězce vybírá jen mezi historiemi, které daný uzel nejprve ověří jako platné; samo proto tento nesoulad nemohlo vyřešit. [1]
Pieter Wuille zveřejnil nouzové upozornění a obchodníkům doporučil pozastavit zpracování plateb. Po debatě vývojářů a provozovatelů přešly pooly BTCGuild vedený Michaelem Marseem, známým jako Eleuthria, a Slush Pool Marka Palatinuse zpět na Bitcoin 0.7. Cílem nebylo prohlásit technicky novější větev za špatnou navždy, ale co nejrychleji soustředit práci na historii, kterou dokázaly ověřit obě rozšířené verze. [3]
Když kompatibilní větev získala převahu v kumulované práci, uzly 0.8 se na ni reorganizovaly a bloky vytěžené pouze na původní větvi 0.8 osiřely. BIP 50 zaznamenává nejméně jeden velký double spend během rozkolu; podle post-mortem šlo o experiment, nikoli zamýšlenou krádež. Událost přesto ukázala, proč burzy a obchodníci při nejasné špičce řetězce zastavují vklady a čekají na další potvrzení. [1]
Bitcoin Core 0.8.1 vyšel 18. března 2013. Zavedl dočasné pravidlo přijímání bloků vynucované od 21. března do 15. května, které bránilo přijetí bloků nezpracovatelných staršími peery, a přidal vestavěný checkpoint na blok 225 430. Post-mortem současně uvádí limit odhadu 10 000 zámků, těžební limit 500 000 bajtů a backporty s limitem 537 000 Berkeley DB zámků. [4]
Dočasná kompatibilita nebyla konečný stav. Provozovatelé starších uzlů měli do 15. května přejít na 0.8.1, aktualizovaný backport nebo výslovně zvýšit limit zámků; těžaři nesměli limit zvyšovat před koordinovaným termínem, aby znovu nevytvořili blok, který zbytek sítě odmítne. Dne 16. srpna 2013 síť přijala blok 252 451 a neopravené uzly definitivně oddělila. [5]
Incident ukázal, že konsenzus netvoří jen popis formátu bloku. Patří do něj přesné chování validačního kódu, knihoven, databázových transakcí, chybových cest i hraničních testů. Následná opatření proto zahrnovala stresové generování transakcí na testnetu, lepší upozornění služeb, sledování dlouhých vedlejších větví a opatrnější koordinaci změn; rychlé zvládnutí krize zároveň odhalilo tehdejší závislost na několika dosažitelných vývojářích a velkých poolech. [1]
Pro nejúplnější obraz čtěte toto heslo společně s Bitcoin Core, Konsensuální pravidla, Hard Fork, Reorg, Full Node, Mining Pool. Opačným směrem na něj odkazují také Schelling Point.
01Rozhodla tehdy jedna skupina, který blockchain je pravý?+
Vývojáři a velké pooly koordinovali nouzový postup, ale nemohli vzdáleně přepsat uzly. BTCGuild a Slush změnily software, kterým jejich těžaři stavěli bloky, a uživatelé provozovali verze s vlastními validačními pravidly. Kompatibilní větev se prosadila až tím, že ji přijalo dost uzlů a získala větší kumulovanou práci pro uzly 0.8.
02Byly obě větve současně platné?+
Záleželo na validační verzi. Bitcoin 0.8 považoval blok 225 430 i navazující větev za platné, zatímco část starších uzlů blok kvůli Berkeley DB limitu odmítla a znala pouze druhou větev. Právě rozdílná odpověď po stejných vstupních datech je konsenzuální selhání; dnešní aktivní historie pokračuje po koordinovaně zvolené kompatibilní větvi.