Malam ketika Bitcoin memiliki dua sejarah yang valid

Blok 225 430 tidak dibuat dengan tujuan untuk membagi jaringan. Namun, blok tersebut berisi lebih banyak input transaksi daripada blok sebelumnya, dan dengan demikian membebani database dengan cara yang mengungkapkan perbedaan antara versi. Bitcoin 0.8 menggunakan LevelDB dan memproses blok tersebut. Versi 0.7 dengan Berkeley DB mengalami masalah dengan jumlah kunci dan berakhir dengan kesalahan.

Hasilnya sangat tidak mencolok. Kedua kelompok simpul mematuhi aturan sebagaimana yang dapat dilakukan oleh program mereka. Cabang yang lebih baru tidak melanggar konsensus yang diinginkan dan simpul yang lebih tua tidak diserang. Jaringan terbagi karena keterbatasan praktis dari satu teknologi basis data yang tidak terdokumentasi.

Penambang dengan versi 0.8 membangun di atas blok baru. Penambang dengan versi yang lebih lama melanjutkan dari pendahulunya. Begitu kedua cabang mendapatkan blok tambahan, pembayaran yang dikonfirmasi pada satu cabang tidak harus ada pada cabang lainnya. Pengguna tidak bisa dengan aman mengandalkan jumlah konfirmasi biasa, sampai jelas, sejarah mana yang akan diterima oleh mayoritas ekonomi.

Cabang yang lebih baru awalnya membawa sekitar enam puluh persen kapasitas. Dalam keadaan normal, rantai dengan jumlah pekerjaan kumulatif yang lebih besar akan mendapatkan keunggulan. Namun, di sini, simpul yang lebih tua tidak dapat menerima blok baru tanpa memperhatikan pekerjaannya. Reorganisasi itu sendiri tidak dapat menghubungkan blok yang perangkat lunak validasi lokal anggap tidak valid.

Insiden tersebut tidak mengungkapkan batas dari aturan sederhana "rantai terpanjang memenangkan". Lebih tepatnya, rantai dengan kerja terbesar di antara rantai-rantai yang simpul akui sebagai sah pada awalnya akan memenangkan. Ketika simpul tidak sepakat tentang kesahihan, hashrate saja tidak cukup untuk menyatukan secara langsung.

Para pengembang menyadari masalah itu ketika ketinggian dan hash simpul yang dipantau mulai berbeda. Komunikasi terpusat di kanal IRC, tempat mereka dapat membandingkan log, kekuatan masing-masing cabang, dan respons pool besar. Gavin Andresen kemudian mencatat garis waktu serta keputusan yang diambil malam itu dalam BIP 50.

Tidak ada pilihan yang jelas antara cabang yang benar dan yang salah. Dukungan untuk versi 0.8 akan mempertahankan rantai dengan jumlah pekerjaan yang lebih besar, tetapi akan memutus sejumlah besar simpul lama. Kembali ke cabang 0.7 berarti harus meyakinkan penambang baru untuk meninggalkan blok yang sudah mereka tambang secara sah dan yang darinya mereka berharap memperoleh imbalan.

Alasan praktis untuk kembali adalah kompatibilitas. Versi 0.8 dapat menerima blok yang lebih kecil yang dibuat untuk cabang yang lebih lama, sedangkan simpul 0.7 tidak dapat menerima blok bermasalah dari cabang baru. Jika kinerja beralih ke cabang yang dapat diterima oleh kedua kelompok, jaringan dapat bersatu kembali tanpa pembaruan paksaan segera untuk semua simpul yang lebih lama.

Keputusan itu bukan perintah yang bisa dikirim Andresen melalui protokol. Para pengembang menghubungi operator pool untuk menjelaskan situasinya. Bursa disarankan menangguhkan setoran. Bitcoin.org menerbitkan peringatan dan meminta pool besar kembali ke versi perangkat lunak yang lebih lama agar jaringan dapat bersatu lagi pada cabang yang kompatibel.

Koordinasi ini berlangsung cepat karena lingkaran peserta kunci masih relatif kecil dan orang-orang saling mengenal dari saluran publik. Kecepatan ini membantu jaringan terhindar dari perpecahan yang lebih lama, tetapi juga menunjukkan ikatan sosial yang menjadi ketergantungan operasional awal. Bitcoin tidak memiliki pemimpin; namun, memiliki orang-orang yang panggilan telepon atau pesan mereka dapat memindahkan bagian besar kapasitas.

Percakapan di IRC tidak memiliki kekuatan hukum maupun kunci administrator rahasia. Maknanya terletak pada fakta bahwa di satu tempat, percakapan itu menyatukan orang-orang dengan kemampuan intervensi yang berbeda. Para pengembang mampu menjelaskan penyebabnya, pool dapat mengalihkan hashrate, bursa dapat menghentikan setoran, dan operator simpul dapat mengubah versi. Setiap langkah memiliki risikonya masing-masing dan tidak ada yang bisa menjamin bahwa pihak lain akan menuruti. Keputusan untuk mendukung cabang yang kompatibel dengan versi 0.7 karenanya bukan perintah teknis dari pusat jaringan, melainkan taruhan terkoordinasi bahwa jalur ini akan memulihkan riwayat bersama paling cepat dengan dampak terkecil pada pengguna. Keberhasilannya tidak dapat dipisahkan dari kecilnya ukuran komunitas saat itu, dan tidak boleh diklaim sebagai prosedur krisis yang universal.

Langkah penentu datang dari BTCGuild, yang dikelola Michael Marsee dengan nama Eleuthria, serta Slush Pool milik Marek Palatinus. Kedua operator beralih dari versi 0.8 kembali ke 0.7 dan mengarahkan daya komputasi ke cabang lama. Langkah ini membantu mengubah perbandingan akumulasi kerja antara kedua riwayat tersebut.

Tidak ada yang gratis dalam tabel. Blok-blok yang ditambang di cabang yang ditinggalkan saat reorganisasi berhenti menjadi bagian dari rantai utama, sehingga hadiah mereka tidak boleh tetap dapat dibelanjakan. BIP 50 secara eksplisit menyebutkan bahwa pool rela mengorbankan sejumlah besar uang untuk mengembalikan jaringan ke cabang bersama.

Saat cabang yang lebih tua mengambil keunggulan, simpul yang diperbarui 0.8 dapat menerima dan mereorganisasi sejarahnya. Simpul lama sudah berada di atasnya. Pembagian tersebut ditutup bukan dengan satu versi yang menghapus versi lainnya dari jarak jauh, melainkan karena sejumlah besar penambang membuat lebih banyak pekerjaan di atas titik yang dapat diverifikasi oleh keduanya.

Selama insiden tersebut, setidaknya terjadi satu double spend besar, yang digambarkan sebagai eksperimen, bukan serangan yang direncanakan. Namun, peristiwa tersebut menunjukkan risiko nyata: transaksi dapat dikonfirmasi pada cabang yang kemudian akan ditinggalkan. Rekomendasi untuk menghentikan deposit tidak dilakukan karena panik; melainkan untuk melindungi layanan dari saldo akuntansi yang didasarkan pada sejarah sementara.

Pada saat itu, pool tidak memiliki jaringan. Mereka bisa mempengaruhi urutan blok dengan kekuatan yang dipercayakan kepada mereka oleh penambang, tetapi mereka tidak bisa memaksa setiap uzel penuh untuk menerima aturan apa pun. Keberhasilan mereka bergantung pada tujuan yang sempit: menciptakan cabang yang dianggap valid oleh simpul lama dan baru, dan memberinya jumlah pekerjaan terbanyak.

Gavin Andresen kemudian mendokumentasikan insiden ini dalam BIP 50. Dokumen itu tidak menyatakan bahwa jaringan bekerja tanpa kesalahan. Isinya menjelaskan penyebab, urutan kejadian, blok yang hilang, pembelanjaan ganda, dan langkah untuk mendeteksi perbedaan serupa lebih awal. Karena analisisnya dipublikasikan, pengalaman malam krisis itu tidak hanya tersimpan dalam ingatan para pesertanya. Pengembang lain pun bisa belajar darinya.

Salah satu pelajaran yang diperoleh adalah bahwa konsensus tidak hanya mencakup aturan yang tertulis dalam komentar atau dokumentasi. Perilaku praktis program yang digunakan secara luas dapat menjadi keterbatasan jaringan, bahkan jika tidak ada yang bermaksud untuk memberinya makna moneter. Migrasi basis data oleh karena itu tidak boleh dianggap sebagai perubahan internal murni, jika dapat mengubah penerimaan blok.

Pelajaran lainnya adalah kebutuhan untuk mengkoordinasikan pembaruan dengan lebih hati-hati dan menguji blok di dekat batas operasional. Versi 0.8 membawa perbaikan kinerja, tetapi perbedaan itu baru terlihat di rantai yang sebenarnya. Setelah insiden tersebut, para pengembang menerapkan batasan sementara dan menyiapkan jalan yang memungkinkan ketergantungan lama untuk dengan aman ditinggalkan kemudian.

Kisah ini kadang-kadang digunakan sebagai bukti bahwa Bitcoin dikendalikan oleh beberapa pengembang, dan kadang-kadang sebagai bukti bahwa itu secara otomatis tidak dapat dihancurkan. Tidak satu pun dari versi yang singkat ini tepat. Orang-orang berhasil mengoordinasikan perbaikan dengan sangat mendesak, tetapi mereka membutuhkan kerja sama dari pool, bursa, dan operator simpul. Perangkat lunak mengambil keputusan pada setiap komputer secara terpisah dan hasil bersama baru terbentuk ketika mereka semua bekerja bersama.

Malam 11–12 Maret berakhir dengan satu rantai utama, tetapi perbedaan tidak hilang dengan sendirinya. Sebagian peserta menemukan masalah, yang lain menangguhkan layanan, dan para penambang merelakan kerja yang sudah dilakukan demi memulihkan riwayat yang kompatibel. Bitcoin melewati dua masa lalunya yang bersaing berkat perpaduan aturan, biaya ekonomi, dan orang-orang yang bersedia mengakui bahwa kali ini perangkat lunak barulah yang harus mengalah.

Nilai BIP 50 terletak pada caranya membahas insiden tanpa menutupnya dengan klaim kemenangan desentralisasi. Dokumen ini mencatat penyebab spesifik, urutan waktu, kerja yang hilang, dan langkah yang direncanakan untuk mencegah kejutan serupa. Kegagalan yang tidak menyenangkan menjadi dasar pengujian berikutnya. Namun, satu pertanyaan tetap terbuka: berapa banyak asumsi tak tertulis yang tersembunyi di antara dua versi program yang kita anggap kompatibel? Konsensus bukan sekadar daftar aturan di atas kertas. Implementasi dan simpul yang independen harus mencapai hasil yang sama, bahkan dalam kasus batas. Pentingnya kesepakatan itu paling jelas terlihat saat kesepakatan tersebut runtuh.