contoh OP_IF akar taproot ini jauh lebih mengkhawatirkan untuk proposal RDTS daripada yang saya sadari sebelumnya. Ini sebenarnya adalah kebijakan dompet miniscript: thresh (3, pk (A), pk (B), pk (C), pk (D), tua (T1), lebih tua (T2)) yang berarti "multisig 3-of-4, meluruh menjadi 2-of-4 setelah waktu T1, dan 1-of-4 setelah waktu T2"

Ada dua pengeluaran terkait secara berturut-turut, masing-masing menjalankan salah satu kondisi pengeluaran timelock. Persis seperti aktivitas yang mungkin Anda harapkan dari seseorang yang melakukan tes mainnet akhir sebelum memasukkan dana nyata ke dompet yang mengandalkan skrip penguncian ini.

karena ini adalah tapscript yang menggunakan OP_IF, dana apa pun yang diterima oleh dompet tersebut setelah aktivasi RDTS akan dibekukan. pemilik juga tidak akan dapat memindahkan koin mereka untuk menyegarkan kunci waktu relatif, mungkin memaksa pengurangan keamanan yang tidak diinginkan dan bencana.

Pertimbangkan, misalnya, bahwa kebijakan miniscript semacam ini dapat digunakan untuk skema warisan atau model hak asuh kolaboratif. misalnya pemilik memegang tiga kunci, dan meneruskan kunci keempat kepada ahli waris atau penyedia layanan kunci pemulihan.

Selama mereka masih hidup, pemiliknya dapat menyegarkan kunci waktu secara berkala dengan mengirim koin kembali ke diri mereka sendiri, mempertahankan kendali tunggal atas dana. Jika mereka kehilangan kunci, mereka dapat menunggu timelock pertama kedaluwarsa, atau meminta pemegang kunci lain untuk membantu memulihkan akses.

Ketika mereka meninggal, ahli waris mendapatkan akses sepihak ke warisan mereka segera setelah timelock kedua berakhir. namun, RDTS membekukan dompet berisiko mencegah pemilik menyegarkan koin mereka tepat waktu, membuatnya rentan terhadap pencurian dini oleh pemegang kunci lainnya

sejauh yang saya tahu, dompet miniscript taproot semacam ini dimungkinkan untuk dibuat di perangkat lunak konsumen saat ini. misalnya, inilah tampilan untuk menyiapkannya sebagai dompet miniscript khusus di aplikasi seluler Nunchuk.