Hard Fork adalah perubahan konsensus ketika himpunan validitas baru bukan himpunan bagian dari himpunan lama. Kasus yang umum adalah perluasan: V(new) mengizinkan keadaan di luar V(old), misalnya blok lebih besar daripada yang diizinkan node lama atau konstruksi yang dianggap tidak valid oleh perangkat lunak lama. Aktivasi aturan baru tidak memaksa node lama beralih; node itu tetap menegakkan aturannya, sehingga kesinambungan bergantung pada koordinasi sukarela.
Nyatakan seluruh blok yang diterima aturan awal sebagai V(old). Perubahan merupakan Hard Fork bila perangkat lunak baru menerima setidaknya satu blok di luar himpunan tersebut. Biasanya himpunan blok valid diperluas, tetapi kriteria penentunya adalah kompatibilitas: jika blok yang valid bagi node baru dapat tidak valid bagi node lama, validator lama tidak dapat mengikuti rantai baru sambil mempertahankan aturannya. [Bitcoin Developer Guide — Consensus rule changes]
Full Node lama tidak mengetahui atau mengakui aturan baru. Begitu penambang yang diperbarui menghasilkan blok yang melampaui batas lama atau memakai konstruksi yang baru diizinkan, node lama tetap pada blok terakhir yang dianggapnya valid dan menolak cabang berikutnya. Node itu tidak kalah dalam pemungutan suara; ia menjalankan program konsensus lain secara deterministik. [Bitcoin Developer Guide — Consensus rule changes]
Tanggal tertentu, ketinggian blok, atau sinyal penambang dapat mengoordinasikan peserta yang menerima pembaruan, tetapi tidak mengubah perangkat lunak node yang tidak menerimanya. Jika masing-masing perangkat aturan masih memiliki peserta penting secara ekonomi, kedua rantai dapat berlanjut. Rencana aktivasi Hard Fork dengan demikian merupakan rencana migrasi dengan risiko perpecahan. [Bitcoin Developer Guide — Consensus rule changes]
Pada titik perpecahan, kedua cabang mewarisi sejarah UTXO sebelumnya yang sama. Sesudahnya, keduanya dapat mengonfirmasi transaksi berbeda, memakai batas berbeda, dan mengakumulasi chainwork yang berbeda. Jika keduanya bertahan, pemegang biasanya memiliki koin yang bersesuaian pada kedua rantai, dengan batasan aturan selanjutnya, perlindungan replay, dan dukungan dompet. Ini bukan lagi satu catatan dalam satu buku besar. [BCHN Technical Bulletin — shared history and 2017 split]
Proof of Work memilih di antara cabang hanya setelah node menyatakan blok-bloknya valid. Node lama tidak membandingkan chainwork cabang yang memuat blok tidak valid menurut aturannya dengan chainwork rantainya sendiri yang valid; kandidat itu dibuang terlebih dahulu. Karena itu, pernyataan ‘rantai dengan hashrate tertinggi menang’ tidak lengkap tanpa menyebutkan aturan validasinya. [Bitcoin Developer Guide — Consensus rule changes]
Format tanda tangan dan transaksi yang sama dapat membuat satu transaksi bertanda tangan valid pada kedua jaringan setelah perpecahan. Itulah risiko replay. Suatu fork dapat menambah perlindungan, aturan sighash berbeda, atau format alamat lain, tetapi semuanya merupakan tindakan tersendiri. Pengguna harus membedakan jaringan, saldo, alamat turunan, serta kebijakan bursa untuk pengkreditan setoran dan penarikan. [Bitcoin Cash upgrade specification — 2017 hard fork]
Bitcoin Cash berpisah dari Bitcoin pada ketinggian blok 478559 tanggal 1 Agustus 2017. Aturannya mengizinkan blok lebih besar daripada yang diterima node Bitcoin saat itu dan membentuk rantai berkelanjutannya sendiri. Node Bitcoin menolak blok yang hanya valid menurut aturan BCH, sedangkan node BCH mengikuti sejarah validnya sendiri. Hard Fork ini membentuk jaringan terpisah, bukan mengganti Bitcoin melalui pembaruan di jaringan yang sama. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]
Tidak setiap perpecahan yang tidak kompatibel merupakan proyek moneter baru yang disengaja. Bug perangkat lunak dapat menyebabkan implementasi berbeda pendapat untuk sementara, dan rilis darurat dapat mengoordinasikan kembalinya peserta ke satu perangkat aturan. Perpecahan Bitcoin pada Maret 2013 berasal dari perbedaan perilaku versi terkait basis data dan batasannya. Peristiwa itu diselesaikan melalui kembalinya penambang secara terkoordinasi ke cabang yang diterima node lama versi 0.7; hal itu berbeda dari mempertahankan BCH sebagai jaringan terpisah dalam jangka panjang. [BIP 50 — March 2013 chain fork post-mortem]
Soft Fork mempersempit himpunan validitas sehingga V(new) tetap berada di dalam V(old). Node lama dapat mengikuti blok yang kompatibel, tetapi tidak menegakkan pembatasan tambahan. Hard Fork tidak memiliki kompatibilitas satu arah ini: blok yang baru menjadi valid dapat tidak valid bagi node lama. Soft Fork juga dapat terpecah bila koordinasi buruk, tetapi Hard Fork menurut definisinya memerlukan migrasi ke aturan baru. [Bitcoin Developer Guide — Consensus rule changes]
Pengembang dapat merilis kode, penambang mengalihkan hashrate, perusahaan memilih simbol perdagangan dan kebijakan setoran, serta pengguna memilih perangkat lunak. Tidak satu pun otomatis menulis ulang konsensus peserta lain. Perpecahan dapat bertahan bila cukup banyak peserta independen secara sukarela mempertahankan dan menghargai kedua perangkat aturan; tidak setiap perubahan yang tidak kompatibel harus menghasilkan dua jaringan yang terus aktif secara permanen. Menamai satu cabang sebagai ‘pembaruan’ adalah kesepakatan sosial, bukan aturan konsensus. [Bitcoin Developer Guide — Consensus rule changes]
Operator perlu memeriksa pengenal jaringan, rilis perangkat lunak tertentu, parameter konsensus, peer, ujung rantai, hash blok di titik fork, serta catatan rilis atau checkpoint yang sesuai. Untuk dana besar, sebaiknya pisahkan dompet dan alur kerja sebelum membelanjakan koin hasil fork. Penjelajah blok atau simbol perdagangan membantu, tetapi tidak menggantikan node sendiri yang memvalidasi aturan. [Bitcoin Core v29.0: getblockchaininfo]
Untuk gambaran yang lebih utuh, baca entri ini bersama Soft Fork, Aturan konsensus, Full Node, Reorg, Perang ukuran blok, UTXO. Entri ini juga dirujuk dari Soft Fork, BIP (Bitcoin Improvement Proposal), Reorg, Perang ukuran blok.