Soft Fork

Mari tandai dengan V(lama) semua blok yang diterima oleh aturan sebelum peningkatan. Perubahannya adalah soft fork hanya jika V(baru) terletak di dalam V(lama): node baru akan menolak kelas blok berikutnya, tetapi blok yang sesuai dengan aturan baru juga akan lolos pemeriksaan lama. Nama tersebut menunjukkan kesesuaian aturan validitas, bukan ukuran, keamanan, atau kesesuaian sosial dari perubahan tersebut. Meningkatkan batas yang terlihat oleh node lama atau mengizinkan pembelanjaan yang sebelumnya tidak valid akan memperluas kumpulan dan biasanya memerlukan hard fork. [Panduan Pengembang Bitcoin — Perubahan aturan konsensus] [Bitcoin Optech — Aktivasi soft fork]

Node penuh yang lama dapat terus mengikuti rantai karena penambang yang diperbarui secara rutin membuat blok yang dikenalinya. Tapi itu tidak memeriksa kondisi tambahan. Jika cabang dengan lebih banyak pekerjaan melanggar aturan baru, node lama dapat menerimanya, sedangkan node yang diperbarui menolaknya. Mereka yang memerlukan garansi baru harus memperbarui perangkat lunak validasi mereka sendiri; kemampuan dompet untuk menerima pembayaran, kompatibilitas format, dan validasi konsensus penuh adalah hal yang berbeda. [Panduan Pengembang Bitcoin — Perubahan aturan konsensus] [BIP 341 — Penerapan akar tunggang]

Bitcoin membuat subset menggunakan beberapa teknik. BIP66 melarang penandatanganan DER yang tidak ketat yang diterima oleh aturan lama. BIP65 dan BIP112 menambahkan ketentuan pada opcode NOP yang dianggap oleh penerjemah lama sebagai tindakan tidak melakukan apa pun yang berhasil. SegWit dan Taproot memberi arti pada versi program saksi yang dicadangkan, yang oleh node lama dianggap dapat dibelanjakan oleh siapa saja. Pada saat yang sama, desain harus mencegah pengelakan pengendalian baru; Oleh karena itu SegWit menyimpan data saksi melalui coinbase dan mempertahankan aturan blok dasar yang lama. [BIP 66 — Tanda tangan DER yang ketat] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Saksi Terpisah] [BIP 341 — Penerapan akar tunggang]

Kode mungkin berisi aturan yang tidak aktif jauh sebelum berlaku di mainnet. BIP dan implementasi yang diperiksa bukanlah penerapan, parameter penerapan tidak dikunci, penguncian hanya merencanakan penerapan di masa mendatang, dan hanya status ACTIVE yang berarti memeriksa blok yang diberikan. Setiap node menghitung status dari nenek moyang cabangnya sendiri. Reorganisasi pada batas mungkin menghitung ulang, dan perangkat lunak dengan parameter berbeda mungkin mulai menerapkan aturan yang tidak kompatibel. [BIP 9 — Bit versi dengan batas waktu dan penundaan] [Bitcoin Core — versionbits.cpp]

BIP9 memberikan nama, versi bit, waktu mulai dan batas waktu penerapan. Varian mainnet asli mengevaluasi periode setelah 2.016 blok: setelah setidaknya 1.916 blok sinyal, yaitu 95%, ia beralih dari STARTED ke LOCKED_IN, menunggu selama satu periode dan kemudian AKTIF; jika tidak, mungkin akan GAGAL. Urutan lengkapnya adalah DEFINED, STARTED, LOCKED_IN, ACTIVE, dan FAILED. Status blok bergantung pada leluhurnya, bukan nVersionnya sendiri, dan pemberian sinyal setelah penguncian tidak lagi mengubah hasilnya. [BIP 9 — Bit versi dengan batas waktu dan penundaan]

Versionbit menunjukkan kesiapan penambang dan mengoordinasikan transisi; mereka tidak memberikan kepemilikan permanen atas konsensus kepada penambang. BIP8 menggunakan ketinggian dan dengan lockinontimeout dapat memaksa pemberian sinyal di jendela terakhir. BIP148, sebaliknya, memerintahkan node yang berpartisipasi untuk menolak blok sinyal non-SegWit; BIP91 menurunkan ambang batas penambangan untuk berkoordinasi dengan tekanan ini. Aktivasi wajib dapat memecah rantai jika node, tingkat hash, dan adopsi ekonomi berbeda, sehingga metode aktivasi pun merupakan kompromi keamanan. [BIP 8 — Bit versi dengan penguncian berdasarkan ketinggian] [BIP 148 — Aktivasi wajib SegWit] [BIP 91 — Mengurangi ambang batas SegWit MASF] [Bitcoin Optech — Aktivasi soft fork]

P2SH di bawah BIP16 diaktifkan pada tahun 2012 dengan pensinyalan coinbase dan batas waktu. BIP34 menggunakan versi blok dan ambang batas untuk ketinggian wajib di coinbase. Prosedur bilangan bulat yang sama menjalankan DER ketat di BIP66 dan CHECKLOCKTIMEVERIFY di BIP65, tetapi menggunakan nilai versi dan tidak dapat melakukan penerapan secara bersamaan. Oleh karena itu BIP9 memperkenalkan bit independen. BIP68, BIP112 dan BIP113 kemudian diaktifkan bersama sebagai waktu penguncian relatif dan CSV pada ketinggian 419.328 pada tahun 2016. [BIP 16 — Bayar ke Script Hash] [BIP 34 — Blok v2, tinggi di coinbase] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Tanda tangan DER yang ketat] [BIP 112 — CHECKSEQUENCEVERIFY]

SegWit diaktifkan di 481.824 pada bulan Agustus 2017. Node lama melihat transaksi tanpa data saksi dan menganggap saksi v0 sebagai siapa pun dapat membelanjakannya; saksi verifikasi yang diperbarui, intisari tanda tangan baru, dan aturan anti-kelenturan. Komitmen Merkle untuk menyaksikan data dalam keluaran coinbase mencegah penambang mengubah atau menghilangkan data tanpa terdeteksi. Penagihan bobot meningkatkan kapasitas efektif tanpa blok yang mendasarinya terlihat oleh node lama melebihi batas lama satu megabita. [BIP 141 — Saksi Terpisah]

BIP341 dan BIP342 menyaksikan pengeluaran jalur kunci dan jalur skrip versi 1 dengan tanda tangan Schnorr dan Tapscript. Node lama lagi-lagi memperlakukan program yang dicadangkan sebagai siapa saja yang dapat membelanjakannya: subset dipertahankan, validasi penuh tidak. Mainnet menggunakan BIP9 Speedy Trial yang dimodifikasi dengan ambang batas 1.815 dari 2.016 blok, atau 90%, dan tinggi aktivasi minimum 709.632. Akar tunggang diaktifkan di dalamnya pada 14 November 2021; Aturan Taproot dan cara mengaktifkannya adalah dua pertanyaan audit terpisah. [BIP 341 — Penerapan akar tunggang] [BIP 342 — Skrip Tap] [Catatan rilis Bitcoin Core 0.21.1 — Penerapan akar tunggang]

Ketika BIP66 diaktifkan pada bulan Juli 2015, beberapa penambang mengisyaratkan versi baru namun tidak cukup memvalidasi blok induk tempat mereka menambang. Mereka memperpanjang blok yang tidak valid dan membuat enam blok cabang tidak valid pada tanggal 4 Juli; insiden singkat lainnya menyusul keesokan harinya. Node validasi yang diperbarui menolak kedua cabang. Nomor versi atau bit merupakan klaim penambang, bukan bukti bahwa ia sendiri yang telah memverifikasi template, induk, dan transaksinya. [BIP 66 — Tanda tangan DER yang ketat] [Bitcoin.org — Peringatan fork rantai BIP66 Juli 2015]

Dalam keadaan ACTIVE, node yang diperbarui menolak blok yang melanggar terlepas dari pembagian tingkat hash; timbul atau tidaknya pembagian permanen tergantung pada pekerjaan cabang-cabang dan kegunaan ekonominya. Menghapus pembatasan saja akan mengaktifkan kembali blok yang tidak valid saat ini dan oleh karena itu merupakan upaya yang sulit; parameter atau kode dapat diganti dengan rilis terkoordinasi sebelum aktivasi. Operator memverifikasi versinya sendiri, getdeploymentinfo atau getblockchaininfo, parameter pasti, tinggi aktivasi, dan log. Baik grafik sinyal maupun label penjelajah tidak dapat menggantikan validasi lokal. [Panduan Pengembang Bitcoin — Perubahan aturan konsensus] [Bitcoin Core — versionbits.cpp] [Catatan rilis Bitcoin Core 0.21.1 — Penerapan akar tunggang]