BIP 110

Bayangkan dua pengelola node menerima blok yang sama. Yang satu menerimanya berdasarkan aturan lama, sedangkan yang lain menolaknya karena pembatasan baru. BIP 110 bekerja sedalam itu: ia akan mengubah keabsahan blok, bukan sekadar kesediaan node meneruskan transaksi atau menyimpannya dalam mempool, ruang tunggu lokal untuk pembayaran yang belum dikonfirmasi. Pemeriksaan pada 2026-10-23 menemukan spesifikasi versi 1.0.1 berstatus Closed, yakni ditutup. Nomor BIP atau program yang diterbitkan bukan bukti adopsi jaringan. Registri menyimpan dokumen dan riwayatnya; ia tidak mengganti aturan tiap node dari jarak jauh. [1] [2]

Setiap output baru memiliki scriptPubKey, skrip yang menentukan syarat membelanjakannya nanti. Proposal membatasi panjangnya hingga 34 byte, atau 83 byte bila diawali OP_RETURN, instruksi yang membuat output terbukti tidak dapat dibelanjakan. Seluruh skrip dihitung. Batas terpisah sebesar 256 byte berlaku untuk tiap muatan data OP_PUSHDATA* dan item argumen dalam witness, informasi pendamping untuk memverifikasi pembelanjaan. Pengecualiannya adalah memasukkan redeemScript, skrip syarat yang diungkapkan, ke scriptSig menurut BIP16. Witness scripts dan Tapleaf scripts sendiri bukan argumen tersebut, tetapi instruksi penyisipan datanya tetap dibatasi. Jadi yang diukur adalah bagian tertentu, bukan panjang total transaksi atau seluruh witness. [1]

Pembatasan juga menyentuh Taproot, cara menyatakan syarat pembelanjaan. Proposal melarang membelanjakan versi witness atau Tapleaf yang belum didefinisikan, tetapi tidak melarang pembuatan output semacam itu. Annex, sebuah bidang tambahan, serta control block di atas 257 byte juga dilarang; control block adalah bukti keanggotaan skrip dalam struktur yang telah dikomitmenkan. Tapscript tidak boleh memuat OP_SUCCESS* bahkan pada kode yang tidak dijalankan, atau menjalankan OP_IF maupun OP_NOTIF apa pun hasil kondisinya. Sebagai rujukan teknis, format yang didefinisikan mencakup P2WPKH, P2WSH, P2TR dengan versi Tapleaf 0xc0, serta P2A dengan program 0x4e73, yang terakhir hanya dengan tumpukan witness kosong. Itu nama format yang presisi, bukan isian yang harus dimasukkan pengguna biasa ke dompet. [1]

UTXO adalah output yang belum dibelanjakan: sejumlah uang tertentu beserta syarat penggunaannya. Proposal mengecualikan input yang membelanjakan UTXO terkonfirmasi sebelum aktivasi. Namun, pengecualian itu tidak membebaskan output baru dalam transaksi yang sama. Tanda tangan yang disiapkan sebelumnya pun tidak melindungi output yang baru tercipta selama masa aktif. Untuk beberapa konstruksi Taproot yang telah ditandatangani, spesifikasi mengakui risiko dana beku atau hilang jika jalur yang direncanakan menjadi tidak sah dan tidak ada alternatif yang dapat digunakan. Ini juga menimbulkan pertanyaan bagi Miniscript, alat penyusun syarat pembelanjaan, dan BitVM, konstruksi untuk memverifikasi perhitungan. Karena itu, tidak tepat menjanjikan bahwa dampaknya hanya mengenai konten nonmoneter. [1] [3]

Penambang dapat menaruh sinyal dukungan dalam blok: di sini bit 4, dengan ambang 1109 dari 2016 blok, sekitar 55 persen. Namun, proposal tidak berhenti pada sinyal sukarela. Jika ambang belum tercapai lebih awal, sinyal diwajibkan pada ketinggian 961632–963647, lalu LOCKED_IN mulai 963648 dan ACTIVE mulai 965664, asalkan rantai tersebut mencapai ketinggian itu. Ketinggian berarti posisi blok dalam rantai. LOCKED_IN menetapkan transisi; ACTIVE berarti pembatasan data benar-benar diberlakukan. Klien sudah akan menolak blok tanpa sinyal selama periode wajib, sehingga node bisa berpisah sebelum batas data berlaku. Batas itu direncanakan berlaku selama 52416 blok sejak aktivasi nyata, lalu masuk EXPIRED dan berhenti diberlakukan; bukan satu tahun kalender yang persis. [1] [4]

Pendukung menginginkan biaya operasi node yang lebih rendah, tekanan lebih kecil pada kumpulan UTXO, lebih sedikit konten yang tidak diinginkan, dan fokus pada pembayaran. Itu menjelaskan motivasi, bukan membuktikan hasil. Pengkritik menyoroti dampak pada skrip yang berguna, pengembangan mendatang, serta risiko jaringan terbelah. Data juga dapat dipotong kecil-kecil: dalam diskusi awal, Peter Todd mendemonstrasikan transaksi yang memuat seluruh proposal saat itu dengan cara tersebut. Bahkan spesifikasi tidak menjanjikan penghapusan steganografi, yakni menyembunyikan informasi di dalam data lain. Membuat penyimpanan lebih mahal berbeda dari mencegahnya sama sekali. Begitu pula kekhawatiran tentang tanggung jawab hukum atas konten tidak dengan sendirinya membuktikan kewajiban hukum tertentu. [1] [3]

Catatan PR 2247 menggambarkan perpecahan pada 2026-08-08 di ketinggian 961632. Rantai utama memuat blok tanpa sinyal yang disyaratkan, sedangkan OCEAN menambang alternatif dengan sinyal. Pada 2026-08-09, Murch melaporkan bahwa cabang minoritas hanya menghasilkan 2 blok lalu berhenti, sementara rantai utama maju lebih dari 100 blok. Laporan seperti ini harus dibaca bersama tanggal dan penulisnya: bukan pemutaran ulang blockchain secara independen untuk artikel ini, juga bukan pernyataan kondisi cabang minoritas hari ini. Ini menunjukkan mengapa perpecahan akibat sinyal tidak sama dengan mencapai ACTIVE dan memberlakukan pembatasan datanya. [5] [6]

Dokumen melewati Complete, yang berarti spesifikasi selesai, lalu berakhir sebagai Closed. PR 2245 untuk menutupnya digabungkan pada 2026-08-10; catatan perubahan spesifikasi bertanggal 2026-08-09. Tanggal itu merujuk pada catatan berbeda, bukan aktivasi tambahan. Rilis klien v0.4.1 mendokumentasikan EXPIRED dan vbrequired, bidang templat blok yang menunjukkan bit sinyal wajib. Keberadaan klien tersebut bukan adopsi dalam Bitcoin Core. Tersedia pula test vectors, contoh transaksi dengan hasil yang diharapkan, serta pengujian fungsional. Artikel ini tidak menjalankannya atau memverifikasi rantai minoritas saat ini. Tujuannya menjelaskan proposal dan sejarah terdokumentasinya, bukan menyajikan dokumen historis sebagai aturan bersama jaringan hari ini. [7] [1] [4]