यह किसी नए नियम पर विवाद नहीं था, बल्कि database implementation पर validation की छिपी निर्भरता थी: नया LevelDB असामान्य रूप से अधिक inputs वाले ब्लॉक को संभाल सका, जबकि पुराने versions ने Berkeley DB के default locks समाप्त कर दिए; miners ने compatible branch पर लौटना समन्वित किया और बाद के 0.8.1 release ने नियंत्रित transition तैयार किया।
11 मार्च 2013 को Bitcoin 0.8 चला रहे एक नोड ने ब्लॉक 225 430 mine किया। नए version ने उसे स्वीकार किया, जबकि 0.7.2 और पुराने versions वाले कुछ नोड ने उसे अस्वीकार किया; इसलिए एक ही parent से उस ब्लॉक वाली branch और उसके बिना branch बढ़ीं। अंतर hash या proof of work में नहीं था, बल्कि इसमें था कि स्थानीय software ब्लॉक को वैध मानता था या नहीं। [2]
कारण केवल bytes में block size नहीं था। ब्लॉक में पहले से कहीं अधिक transaction inputs थे और पुराने नोड ने उन्हें लिखते समय Berkeley DB के default locks समाप्त कर दिए। आवश्यक locks की संख्या हर नोड की database pages की व्यवस्था पर भी निर्भर थी, इसलिए छोटा लेकिन अन्यथा वैध ब्लॉक वहाँ विफल हो सकता था जहाँ पहले maximum-size test blocks सफल हुए थे। [1]
Bitcoin 0.8 ने block और transaction indexes को Berkeley DB से LevelDB में स्थानांतरित किया, जिसमें वही lock सीमा नहीं थी। शुरुआत में लगभग 60 % hashrate 0.8 branch पर काम कर रहा था, लेकिन पुराने नोड ने उसके काम को नहीं गिना क्योंकि उन्होंने पहला ब्लॉक अस्वीकार किया था। heaviest-chain rule केवल उन्हीं histories में चुनता है जिन्हें नोड पहले वैध ठहरा चुका हो, इसलिए वह अकेले इस असहमति को हल नहीं कर सका। [1]
Pieter Wuille ने emergency warning प्रकाशित की और merchants को payment processing रोकने की सलाह दी। developers और operators की चर्चा के बाद Michael Marsee, जिन्हें Eleuthria कहा जाता था, के BTCGuild और Marek Palatinus के Slush Pool ने Bitcoin 0.7 पर वापसी की। उद्देश्य तकनीकी रूप से नई branch को हमेशा के लिए गलत घोषित करना नहीं, बल्कि काम को उस history पर शीघ्र केंद्रित करना था जिसे दोनों व्यापक versions validate कर सकें। [3]
जब compatible branch cumulative work में आगे हुई, 0.8 नोड ने उस पर reorg किया और केवल मूल 0.8 branch पर mine हुए blocks stale हो गए। BIP 50 विभाजन के दौरान कम से कम एक बड़ा double spend दर्ज करता है; post-mortem के अनुसार वह प्रयोग था, चोरी का इरादा नहीं। फिर भी घटना ने दिखाया कि chain tip अनिश्चित होने पर exchanges और merchants deposits क्यों रोकते हैं और अधिक confirmations की प्रतीक्षा क्यों करते हैं। [1]
Bitcoin Core 0.8.1, 18 मार्च 2013 को जारी हुआ। इसने 21 मार्च से 15 मई तक लागू अस्थायी block-acceptance rule जोड़ा, जो ऐसे blocks को स्वीकार करने से रोकता था जिन्हें पुराने peers process नहीं कर सकते थे, और ब्लॉक 225 430 पर built-in checkpoint जोड़ा। post-mortem में 10 000 locks की अनुमानित सीमा, 500 000 bytes की mining सीमा और 537 000 Berkeley DB locks वाले backports भी दिए गए हैं। [4]
अस्थायी compatibility अंतिम अवस्था नहीं थी। पुराने नोड operators को 15 मई तक 0.8.1, updated backport या स्पष्ट रूप से बढ़ी lock सीमा पर जाना था; miners को coordinated date से पहले सीमा नहीं बढ़ानी थी, ताकि वे फिर ऐसा ब्लॉक न बनाएँ जिसे बाकी network अस्वीकार करे। 16 अगस्त 2013 को network ने ब्लॉक 252 451 स्वीकार किया और unpatched नोड को स्थायी रूप से पीछे छोड़ दिया। [5]
घटना ने दिखाया कि consensus केवल block format का वर्णन नहीं है। इसमें validation code, libraries, database transactions, error paths और boundary tests का सटीक व्यवहार शामिल है। बाद के कदमों में testnet पर stress transactions बनाना, services के लिए बेहतर alerts, लंबी side branches की निगरानी और changes का अधिक सावधान coordination शामिल था; तेज recovery ने उस समय कुछ उपलब्ध developers और बड़े pools पर network की निर्भरता भी उजागर की। [1]
पूरी तस्वीर के लिए इस प्रविष्टि के साथ यह भी पढ़ें Bitcoin Core, सहमति के नियम, Hard Fork, Reorg, Full Node, Mining Pool. इस प्रविष्टि का उल्लेख यहाँ भी है Schelling Point.
01क्या एक समूह ने तय किया कि कौन-सी blockchain असली है?+
Developers और बड़े pools ने emergency response समन्वित किया, पर वे नोड को दूर से दोबारा नहीं लिख सकते थे। BTCGuild और Slush ने अपने miners का software बदला, जबकि users अपने validation rules वाले versions चलाते रहे। Compatible branch तभी प्रबल हुई जब पर्याप्त नोड ने उसे स्वीकार किया और Bitcoin 0.8 नोड की दृष्टि में उसने अधिक work इकट्ठा किया।
02क्या दोनों branches एक साथ valid थीं?+
यह validating version पर निर्भर था। Bitcoin 0.8 ने ब्लॉक 225 430 और उसकी branch को valid माना, जबकि कुछ पुराने नोड ने Berkeley DB सीमा के कारण ब्लॉक अस्वीकार किया और केवल दूसरी branch को जाना। एक ही input पर अलग उत्तर मिलना ही consensus failure है; आज का active history समन्वित रूप से चुनी compatible branch से जारी है।