Bayangkan Timelock sebagai aturan “jalur ini baru boleh dipakai nanti”. Acuannya bisa berupa tinggi blok, yaitu posisi blok dalam rantai, waktu yang dihitung dari rantai, atau jeda sejak suatu output terkonfirmasi. Output adalah sejumlah dana dengan aturan tentang siapa yang boleh membelanjakannya dan dengan syarat apa. Menunggu tidak menggantikan tanda tangan atau persyaratan lain, dan tidak mengirim uang dengan sendirinya. Bedakan pula pembatasan satu transaksi yang disiapkan dengan syarat yang ditegakkan oleh aturan pembelanjaan dana itu sendiri.
Anna dan Pavel bisa mengatur dana bersama agar dapat mereka belanjakan berdua kapan saja, tetapi Anna baru boleh membelanjakannya sendiri setelah jeda tertentu. Jika Pavel berhenti merespons, cabang tertunda menyediakan jalur pemulihan yang disepakati sebelumnya. Cabang di sini berarti salah satu cara pembelanjaan yang diizinkan; masing-masing dapat memiliki syarat berbeda. Jadi, kunci tidak harus menutup semua pilihan sekaligus. Aturan harus menjadi bagian dari output sejak dibuat. Menambahkan catatan “buka seminggu lagi” ke dompet biasa belakangan tidak cukup. Setelah menunggu pun, Anna tetap memerlukan kunci yang sesuai serta informasi untuk membuat transaksi valid. Timelock mengatur akses, bukan memulihkan kunci yang hilang. [3]
Kunci absolut menetapkan batas tetap yang dicatat pada kolom nLockTime dalam transaksi. Jika nLockTime yang berlaku pada transaksi diatur ke tinggi 1 000 000, blok paling awal yang memenuhi syarat itu adalah 1 000 001: nilai yang sama belum cukup. Kunci relatif mengukur jeda sejak konfirmasi output yang dibelanjakan. Jika output Anna dibuat pada blok 1 000 000 dan cabangnya mensyaratkan jeda 6 blok, pembelanjaannya dapat memenuhi syarat itu paling awal pada blok 1 000 006. Angka ini contoh, bukan tinggi jaringan saat ini. Syarat tanda tangan, input lain, dan kunci tambahan tetap berlaku. Enam blok juga tidak persis satu jam: blok datang dengan selang tak menentu. Penantian relatif tidak dimulai saat dompet dibuat atau ketika Anna memutuskan memakai uangnya. [1] [2] [5]
Misalkan jeda Anna baru saja selesai. Jaringan tidak akan bertindak untuknya. Seseorang masih perlu membuat atau memakai transaksi yang disiapkan, memberikan tanda tangan, membayar biaya, dan mengirimnya ke jaringan. Barulah penambang dapat memasukkannya ke blok. Timelock yang terpenuhi adalah satu syarat yang selesai, bukan pemesanan tempat atau transfer otomatis. Biasanya ia menetapkan awal kemungkinan membelanjakan, bukan saat pilihan itu berakhir sendiri. Dalam reorganisasi, sebagian rantai diganti oleh cabang valid lainnya. Hal ini dapat mengubah konfirmasi output dan hitungan jeda relatifnya. Untuk rancangan sendiri, periksa lebih dahulu semua cabang, dukungan dompet, serta cadangan kunci dan aturan pembelanjaan; waktu tidak memperbaiki syarat yang salah ditetapkan. [2] [5]
Syarat berbasis waktu menggunakan Median Time Past, disingkat MTP. Untuk blok yang diperiksa, ini adalah median cap waktu dari 11 blok terakhir yang berakhir pada blok sebelumnya. Urutkan waktunya dan ambil yang tengah, yaitu keenam: itulah median, bukan rata-rata aritmetika. BIP113 menjelaskan aturan ini dan Bitcoin Core memakai GetMedianTimePast untuk menghitungnya. Waktu penentu bukan jam ponsel Anna saat ini ataupun cap waktu blok yang diusulkan. Tengah malam pada kalender belum tentu saat kunci terpenuhi. Kunci berbasis tinggi menunggu blok, bukan menghitung mundur detik. [4]
Sekarang kita bisa membedakan empat nama dalam dokumentasi. nLockTime adalah kolom pada seluruh transaksi untuk batas absolut. nSequence pada input memuat jeda relatif menurut BIP68. Namun, nLockTime saja tidak mengunci UTXO, output yang belum dibelanjakan, terhadap transaksi lain dengan pengaturan berbeda. Orang yang berwenang membelanjakan dapat membuat transaksi lain itu jika aturan output tidak melarangnya. Bitcoin Script adalah bahasa untuk menuliskan aturan pembelanjaan tersebut. OP_CHECKLOCKTIMEVERIFY, atau CLTV menurut BIP65, mewajibkan pengaturan absolut yang sesuai pada cabang yang digunakan. OP_CHECKSEQUENCEVERIFY, atau CSV menurut BIP112, memeriksa pengaturan relatif, sedangkan BIP68 menegakkan jeda sebenarnya. CLTV maupun CSV tidak mengirim uang atau melengkapi tanda tangan yang hilang. Cabang lain yang diizinkan bisa digunakan dengan syarat berbeda. [1] [2] [3]
Bagian berikut adalah referensi teknis. Field atau kolom adalah data yang disimpan dalam transaksi; input merujuk output yang akan dibelanjakan. Setiap input memiliki nSequence. Nilai khusus dapat menonaktifkan efek nLockTime, sehingga memasukkan tanggal saja tidak cukup. nLockTime adalah field 32-bit untuk bilangan yang tidak negatif; nol menonaktifkan syarat waktu absolut. Jika semua input memakai SEQUENCE_FINAL dengan nilai 0xffffffff, nLockTime yang belum terpenuhi diabaikan. Kunci absolut yang efektif memerlukan setidaknya satu input dengan nSequence berbeda. Yang dievaluasi adalah transaksi tertentu itu, bukan pembekuan permanen inputnya. [5] [7]
Satu kolom dapat menyatakan dua hal, dipisahkan oleh ambang angka. Unix timestamp menyatakan waktu sebagai detik sejak awal 1970 dalam UTC. Blok kandidat adalah blok yang akan memuat transaksi yang sedang diperiksa. LOCKTIME_THRESHOLD bernilai 500000000. nLockTime lebih rendah berarti tinggi blok; nilai sama atau lebih tinggi berarti Unix timestamp. Saat pemeriksaan absolut aktif, nLockTime harus benar-benar lebih kecil daripada tinggi blok kandidat atau MTP yang relevan. Nilai sama tidak cukup; ini bukan jumlah uang, tinggi rata-rata, atau tanggal aktivasi protokol. [5] [8]
Operand adalah nilai yang diberikan kepada instruksi; opcode adalah instruksi Script itu sendiri. CLTV membandingkan persyaratan tersimpan pada cabang dengan pengaturan transaksi. Pemeriksaan terpisah menentukan apakah rantai sudah cukup maju. Ini lebih dari sekadar membandingkan tanggal hari ini dengan satu angka. OP_CHECKLOCKTIMEVERIFY mewajibkan operand tidak negatif, jenis tinggi/waktu yang sama dengan nLockTime, dan nilai operand tidak melebihi nLockTime. Input pembelanjaan terkait tidak boleh memiliki nSequence 0xffffffff. Opcode tidak membaca jam atau tinggi rantai secara langsung; pengaturan transaksi diperiksa terpisah ketika menilai validitas waktunya. Syarat Script lainnya tetap wajib. [1] [6]
Angka nSequence memuat masa tunggu dan sakelar yang menentukan maknanya. Bit adalah nol atau satu dalam penulisan ini; menyetelnya dapat mengaktifkan pilihan. Posisi bit berikut adalah bagian format teknis, bukan jumlah konfirmasi. Untuk transaksi versi 2 atau lebih tinggi, BIP68 mengaktifkan syarat relatif pada input tanpa bit 31 yang disetel. Sebanyak 16 bit terbawah menentukan jeda; bit 22 memilih satuan 512 detik, jika tidak maka satuannya blok. Jeda blok dihitung dari tinggi konfirmasi output yang dibelanjakan. Jeda waktu dihitung dari MTP blok sebelum konfirmasi tersebut hingga MTP sebelum blok kandidat. Ini bukan waktu sejak transaksi dibuat di dompet. [2] [5]
CSV melakukan pemeriksaan serupa untuk penantian relatif. Mask memilih bit nSequence yang relevan; disable flag adalah sakelar penonaktifan. Lightning Network adalah jaringan kanal pembayaran: para peserta memperbarui pembagian dana yang dikunci bersama sesuai kesepakatan. Jeda memberi pihak lain waktu untuk merespons jika seseorang menerbitkan keadaan lama yang sudah dicabut. Commitment transaction mencatat pembagian dana; kunci pencabutan memungkinkan pihak lain membelanjakan output terkait dari versi yang dicabut melalui cabang penalti. OP_CHECKSEQUENCEVERIFY dengan operand aktif yang tidak negatif mewajibkan versi setidaknya 2, disable flag input tidak disetel, jenis jeda sama, dan nSequence setelah masking yang mencukupi. Usia sebenarnya ditegakkan terpisah oleh BIP68. CSV memungkinkan cabang pemulihan tertunda. Pada output Lightning to_local, to_self_delay membatasi pemilik commitment transaction; pihak lain dengan kunci pencabutan yang benar dapat memakai cabang penalti tanpa jeda itu. [3] [9]
Dua angka yang hampir sama bisa berefek berbeda. Nilai berikut yang dimulai dengan 0x ditulis dalam heksadesimal. NOP berarti instruksi yang tidak menambah pembatasan waktu di sini. Letak sakelar juga penting: pada input transaksi atau pada nilai yang diberikan kepada CSV. Bit 31 adalah SEQUENCE_LOCKTIME_DISABLE_FLAG dan menonaktifkan interpretasi relatif BIP68 hanya untuk input itu. Nilai 0xfffffffe memuat bit tersebut tetapi bukan SEQUENCE_FINAL: nLockTime dan CLTV tetap dapat berlaku efektif. Nilai 0xffffffff adalah final. Operand CSV tidak negatif dengan disable flag disetel berperilaku sebagai NOP; namun flag itu pada input tidak memenuhi persyaratan CSV yang aktif. Kedua kasus ini tidak boleh tertukar. [3] [7]
RPC adalah perintah untuk bekerja dengan nodemu, yaitu program yang memverifikasi blok dan transaksi Bitcoin. Decoding hanya mengubah data tersimpan menjadi daftar yang bisa dibaca; perintah pengujian memeriksa apakah transaksi bertanda tangan tertentu akan lolos. Mempool adalah daftar transaksi tertunda lokal milik node. RPC decoderawtransaction pada Core 31 menampilkan version, locktime, dan sequence setiap input. Untuk CLTV/CSV, periksa Script yang benar-benar digunakan serta output yang dibelanjakan; decoding saja bukan bukti validitas. RPC testmempoolaccept menguji kandidat bertanda tangan terhadap rantai saat ini, aturan validitas Bitcoin, dan aturan penerimaan transaksi lokal milik node, tanpa menerima ke mempool atau menyiarkannya. Periksa allowed dan alasan penolakan; keberhasilan bukan janji konfirmasi mendatang. [10] [11] [12]
Untuk gambaran yang lebih utuh, baca entri ini bersama CLTV, CSV, Lightning Network, Payment Channel, Transaksi, Bitcoin Script. Entri ini juga dirujuk dari Konfirmasi, Bitcoin Script, HTLC, CLTV.