CLTV

Anna merancang penyimpanan yang mengharuskan dirinya dan Peter menyetujui pembayaran biasa bersama-sama. Untuk menghadapi ketidakhadiran yang lama, ia juga menginginkan jalur pemulihan yang baru bisa digunakan setelah batas tertentu. CLTV dapat memasukkan syarat waktu ini ke dalam skrip, yaitu aturan untuk membelanjakan koin yang sebelumnya diterima. Kolom nLockTime saja hanya menunda satu transaksi tertentu. CLTV mencegah orang mengakali jalur itu dengan transaksi baru yang menggunakan batas lebih rendah. Cabang lain tetap bisa memiliki aturan berbeda. [1] [5]

CLTV tidak mengenali pemilik atau mengirim uang. Jika jalur pemulihan memerlukan tanda tangan Anna, ia tetap harus menyediakannya setelah syarat waktu terpenuhi. Kunci privat adalah nilai angka rahasia yang digunakan untuk membuat tanda tangan tersebut. Berlalunya waktu tidak mengembalikan kunci privat yang hilang. Koin juga tidak otomatis pindah ke alamat lain: seseorang harus menyiapkan, menandatangani, dan menyiarkan transaksi yang sah. Jika cabang lain mengizinkan pembelanjaan lebih awal, kunci waktu di cabang pemulihan tidak dengan sendirinya membatasi alternatif tersebut. [1]

Blok mengelompokkan transaksi dalam satu kumpulan yang ditambahkan ke riwayat bersama. CLTV cocok untuk syarat yang terkait dengan titik yang ditentukan sebelumnya, bukan tuntutan menunggu sejumlah blok sejak koin diterima. Pilihan kedua ditangani CSV bersama BIP 68, aturan penguncian relatif. Dalam hal itu, konfirmasi keluaran tertentu menjadi acuan: sejumlah dana yang diterima beserta syarat pembelanjaannya. Tidak satu pun pendekatan menjamin tanggal kalender yang tepat. Laju penambangan berubah-ubah, dan reorganisasi dapat mengubah riwayat yang sudah dikonfirmasi. Dalam reorganisasi, jaringan beralih ke cabang rantai lain yang sah dan mengganti sebagian riwayat blok sebelumnya. [1] [7] [8] [9]

CLTV membedakan dua jenis nilai. Di bawah 500000000, nilai berarti ketinggian blok, yakni posisinya dalam rantai. Mulai batas itu, nilai berarti timestamp, waktu yang ditulis sebagai angka. Syarat skrip dan nLockTime pada transaksi pembelanjaan harus menggunakan jenis yang sama. Membandingkan besar angkanya saja tidak cukup: posisi blok dan waktu bukanlah ukuran dengan arti yang sama. [1] [3] [5]

Full Node memeriksa aturan secara mandiri. Ia membandingkan batas nonnegatif dalam skrip dengan nLockTime absolut transaksi. Batas itu tidak boleh melebihi nLockTime; nilai yang sama diperbolehkan dalam pemeriksaan ini. Transaksi juga harus memenuhi aturan untuk masuk ke blok tertentu. CLTV tidak membaca jam komputer atau menghentikan program sampai besok pagi. Jika pemeriksaan gagal, upaya menggunakan jalur pembelanjaan tersebut tidak sah. [1] [3] [4]

Masukan transaksi menunjukkan koin yang pernah diterima dan kini dibelanjakan. Salah satu kolomnya adalah nSequence. Pada masukan yang diperiksa CLTV, nilainya tidak boleh 0xffffffff, penanda khusus urutan final. Jika semua masukan memakai nilai itu, nLockTime dapat dinonaktifkan. CLTV mencegahnya dengan mewajibkan urutan nonfinal pada masukan tersebut. Namun, ini tidak otomatis menetapkan masa tunggu relatif tertentu; hal itu diatur oleh aturan lain. [1] [3] [4]

Ambil transaksi contoh dengan nLockTime sebesar 900000 dan masukan nonfinal. Untuk syarat waktu ini, blok paling awal yang memungkinkan adalah 900001. Agar dapat dimasukkan, nLockTime harus benar-benar lebih kecil daripada ketinggian calon blok. Blok 900000 belum cukup, meskipun perbandingan di dalam CLTV mengizinkan kesamaan. “Finalitas” di sini berarti kelayakan untuk dimasukkan, bukan pembayaran yang tidak dapat dibalik. Biaya, syarat lain, dan pilihan penambang masih dapat menunda konfirmasi. [4]

Untuk timestamp, BIP 113 menggunakan Median Time Past blok sebelumnya: nilai tengah dari waktu hingga 11 blok terakhir setelah diurutkan. Ini bukan jam tangan Anda atau waktu blok yang sedang ditambang. nLockTime berbasis waktu harus benar-benar lebih kecil daripada nilai itu. Karena itu, koin tidak bisa dijanjikan dapat dibelanjakan tepat pada tengah hari setempat. Syaratnya dapat diverifikasi jaringan, tetapi bukan jadwal pembayaran yang presisi. [2] [4]

Saat dievaluasi, skrip menggunakan stack, tempat kerja yang menumpuk data. CLTV memeriksa argumen waktunya tanpa menghapusnya. Dalam skema sederhana, OP_CHECKLOCKTIMEVERIFY diikuti OP_DROP untuk menghapus argumen; lalu kunci publik dimasukkan dan OP_CHECKSIG memverifikasi tanda tangan. Kunci publik digunakan untuk memeriksa tanda tangan dan tidak perlu dirahasiakan. Ini menjelaskan peran instruksi, bukan resep siap pakai untuk mengunci uang. Versi skrip, data awal, dan seluruh jalur pembelanjaan lainnya juga harus benar. [1] [3]

BIP 65 memperkenalkan CLTV melalui soft fork, pengetatan aturan yang menggantikan OP_NOP2 terdahulu. Jadi ini bukan sekadar usulan fitur masa depan. Namun, seluruh rancangan tetap harus diperiksa: jenis batas, nLockTime, nSequence, tanda tangan, dan cabang alternatif. Bitcoin Core v29.0 serta spesifikasi yang ditautkan mendokumentasikan rinciannya. Bagi pengguna, pertanyaan utamanya adalah siapa yang bisa membelanjakan dana sebelum dan sesudah batas, serta apakah pilihan pemulihannya dipahami. [1] [3] [6] [10]