Ini bukan perselisihan atas aturan baru, melainkan ketergantungan tersembunyi validasi pada implementasi basis data: LevelDB yang lebih baru menangani blok dengan jumlah input tidak biasa, sedangkan versi sebelumnya menghabiskan jumlah default lock Berkeley DB; penambang lalu mengoordinasikan kembali ke cabang kompatibel dan rilis 0.8.1 berikutnya menyiapkan transisi terkendali.
Pada 11 Maret 2013, sebuah node yang menjalankan Bitcoin 0.8 menambang blok 225 430. Versi baru menerimanya, sedangkan sebagian node versi 0.7.2 dan lebih lama menolak; dari induk yang sama lalu tumbuh cabang yang memuat blok itu dan cabang tanpa blok tersebut. Perbedaannya bukan pada hash atau proof of work, melainkan apakah perangkat lunak lokal menganggap blok itu valid sejak awal. [2]
Pemicunya bukan sekadar ukuran blok dalam byte. Blok tersebut memuat jumlah input transaksi yang belum pernah terlihat, dan node lama menghabiskan jumlah default lock Berkeley DB ketika menulisnya. Jumlah lock yang diperlukan juga bergantung pada susunan halaman basis data masing-masing node, sehingga blok lebih kecil yang sebenarnya valid dapat gagal meski blok uji berukuran maksimum sebelumnya berhasil. [1]
Bitcoin 0.8 memindahkan indeks blok dan transaksi dari Berkeley DB ke LevelDB, yang tidak memiliki batas lock yang sama. Pada awalnya sekitar 60 % hashrate membangun di cabang 0.8, tetapi node lama tidak menghitung kerjanya karena menolak blok awal. Aturan rantai terberat hanya memilih di antara riwayat yang lebih dulu divalidasi node, sehingga tidak dapat menyelesaikan perbedaan ini sendirian. [1]
Pieter Wuille menerbitkan peringatan darurat dan menyarankan pedagang menghentikan pemrosesan pembayaran. Setelah diskusi pengembang dan operator, BTCGuild yang dipimpin Michael Marsee, dikenal sebagai Eleuthria, serta Slush Pool milik Marek Palatinus kembali ke Bitcoin 0.7. Tujuannya bukan menyatakan cabang yang secara teknis lebih baru salah selamanya, melainkan segera memusatkan kerja pada riwayat yang dapat divalidasi kedua versi yang luas digunakan. [3]
Ketika cabang kompatibel memimpin dalam kerja kumulatif, node 0.8 melakukan reorg ke sana dan blok yang hanya ditambang pada cabang 0.8 awal menjadi stale. BIP 50 mencatat setidaknya satu double spend besar selama perpecahan; menurut post-mortem, itu eksperimen, bukan pencurian yang disengaja. Peristiwa ini tetap menunjukkan mengapa bursa dan pedagang menjeda deposit serta menunggu konfirmasi tambahan ketika ujung rantai tidak pasti. [1]
Bitcoin Core 0.8.1 dirilis pada 18 Maret 2013. Versi ini memperkenalkan aturan penerimaan blok sementara yang diberlakukan dari 21 Maret sampai 15 Mei untuk mencegah penerimaan blok yang tak dapat diproses peer lama, serta checkpoint bawaan pada blok 225 430. Post-mortem juga menetapkan perkiraan batas 10 000 lock, batas penambangan 500 000 byte, dan backport dengan batas 537 000 lock Berkeley DB. [4]
Kompatibilitas sementara bukan keadaan akhir. Operator node lama harus beralih sebelum 15 Mei ke 0.8.1, backport terbaru, atau secara eksplisit menaikkan batas lock; penambang tidak boleh menaikkannya sebelum tanggal terkoordinasi agar tidak kembali membuat blok yang ditolak seluruh jaringan lainnya. Pada 16 Agustus 2013, jaringan menerima blok 252 451 dan secara permanen meninggalkan node yang belum ditambal. [5]
Insiden ini menunjukkan bahwa konsensus lebih dari deskripsi format blok. Ia mencakup perilaku tepat kode validasi, library, transaksi basis data, jalur error, dan pengujian batas. Tindak lanjutnya meliputi pembuatan transaksi stres di testnet, peringatan layanan yang lebih baik, pemantauan cabang samping panjang, dan koordinasi perubahan yang lebih hati-hati; pemulihan cepat juga mengungkap ketergantungan jaringan saat itu pada beberapa pengembang yang dapat dihubungi dan pool besar. [1]
Untuk gambaran yang lebih utuh, baca entri ini bersama Bitcoin Core, Aturan konsensus, Hard Fork, Reorg, Full Node, Mining Pool. Entri ini juga dirujuk dari Schelling Point.
01Apakah satu kelompok menentukan blockchain mana yang asli?+
Pengembang dan pool besar mengoordinasikan tanggap darurat, tetapi tidak dapat menulis ulang node dari jarak jauh. BTCGuild dan Slush mengganti perangkat lunak penambangnya, sementara pengguna menjalankan versi dengan aturan validasi masing-masing. Cabang kompatibel menang hanya setelah cukup banyak node menerimanya dan mengumpulkan lebih banyak kerja menurut node Bitcoin 0.8.
02Apakah kedua cabang valid pada waktu yang sama?+
Itu bergantung pada versi yang memvalidasi. Bitcoin 0.8 menganggap blok 225 430 dan cabangnya valid, sedangkan beberapa node lama menolak blok karena batas Berkeley DB dan hanya mengenal cabang lain. Jawaban berbeda atas input yang sama adalah kegagalan konsensus; riwayat aktif saat ini berlanjut dari cabang kompatibel yang dipilih secara terkoordinasi.