Dead Man’s Switch

Suatu model dapat memberi pemilik cabang langsung dan kunci lain cabang yang tersedia setelah menunggu. Syarat yang sama dapat terjadi saat rawat inap, kehilangan perangkat, atau kelalaian pemeliharaan. Akses teknis tidak membuktikan keadaan seseorang maupun ahli waris yang berhak. Sebelum merancangnya, tentukan peristiwa tepat yang benar-benar diamati sistem. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net mengirim email yang disiapkan setelah konfirmasi berkala terlewat. Ini lapisan yang berbeda dari Bitcoin Script. Untuk rancangan sendiri, nilai secara terpisah ketersediaan akun, pengiriman kepada penerima, dan pengungkapan terlalu dini. Pesan dapat menunjukkan lokasi cadangan, tetapi tidak membuktikan syarat pembelanjaan terpenuhi. Seed yang telah dikirim tidak dapat ditarik kembali dengan mengganti timer; kebocoran juga memerlukan penanganan kendali atas koin. [Dead Man’s Switch — Service mechanism]

BIP 65 dan OP_CHECKLOCKTIMEVERIFY memeriksa ambang ketinggian atau waktu absolut. BIP 112 dan OP_CHECKSEQUENCEVERIFY bersama BIP 68 dapat menegakkan umur UTXO tertentu. Penguncian relatif berbasis waktu memakai satuan 512 detik dan median-time-past, bukan jam ponsel; BIP 113 menjelaskan median cap waktu 11 blok sebelumnya. Jangka waktu dalam blok bukan tenggat kalender yang pasti. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Jika UTXO yang dikonfirmasi pada H memiliki cabang pemulihan setelah 1000 blok, cabang itu dapat digunakan paling awal pada H+1000 dengan syarat lain terpenuhi. Masuk ke aplikasi atau menerima dana pada output lain tidak mereset umurnya. Memperbarui jangka waktu relatif mengharuskan output itu dibelanjakan dan output baru dengan kebijakan yang dimaksud dikonfirmasi. Pantau setiap UTXO secara terpisah: pembaruan sebagian dompet dapat menyisakan koin lama dekat ambang. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

Dalam model dengan cabang utama yang selalu tersedia, berakhirnya masa tunggu tidak mencabut kewenangannya. Cabang pemulihan yang dapat digunakan ditambahkan; seseorang tetap harus menandatangani dan menyiarkan transaksi. Jika kedua cabang valid, transaksi terkonfirmasi menentukan pembelanjaan UTXO yang sama, bukan label “pemilik” atau “ahli waris” dalam aplikasi. Rancangan harus menangani pembaruan terlambat dan pembelanjaan yang bersaing. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

nLockTime saja menunda transaksi tertentu; itu tidak membuktikan bahwa kunci berwenang tidak dapat menandatangani pembayaran lain. Rencana yang ditandatangani sebelumnya harus menetapkan input, output, kewenangan tanda tangan, dan pendanaan biaya. Jika transaksi terkonfirmasi lain membelanjakan input tersebut, tanda tangan awal tidak dapat digunakan. Mengubah dokumen saja tidak cukup: periksa UTXO aktual dan ketersediaan bahan baru bagi penerima. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Mekanisme ini menyiratkan perlunya jeda cadangan sebelum tenggat terdekat, pemberitahuan yang berfungsi, dan dana biaya. Pembaruan lebih sering memerlukan biaya transaksi; waktu tunggu lebih panjang memperpanjang ketidaktersediaan pemulihan. Orang yang memulihkan membutuhkan kunci tepat, deskripsi kebijakan seperti descriptor, dan alat yang dapat digunakan. Cadangan yang terkunci di balik akun atau perangkat pemilik yang tidak tersedia menciptakan ketergantungan melingkar. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana menyediakan panduan Signet. Lingkungan uji terpisah dapat memeriksa percobaan terlalu dini, matangnya cabang pemulihan, dan pembaruan output tertentu. Tambahkan skenario pemberitahuan tidak terkirim, hilangnya kunci utama, dan pemulihan dari bahan tersimpan. Periksa apa yang masih diizinkan kunci dan UTXO lama setelah penerima diganti. Bedakan penandatanganan, penerimaan mempool, dan konfirmasi: satu skenario berhasil tidak membuktikan seluruh rencana bebas kesalahan. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]