цей приклад OP_IF стрижневого кореня викликає набагато більше занепокоєння щодо пропозиції RDTS, ніж я спочатку усвідомлював. Насправді це політика гаманця Miniscript: молотьба(3,pk(A),pk(B),pk(C),pk(D),старша(T1),старша (T2)) означає «мультипідпис 3 з 4, що зменшується до 2 з 4 після часу Т1 і 1 з 4 після часу Т2»

Існують два пов'язаних між собою витрати, кожен з яких виконує одну з умов витрат Timelock. Саме такої активності ви можете очікувати від людини, яка проводить фінальні тести основної мережі перед завантаженням реальних коштів у гаманець, який покладається на цей сценарій блокування.

оскільки це tapscript з використанням OP_IF, будь-які кошти, отримані таким гаманцем після активації RDTS, будуть заморожені. Власник також не зможе перемістити свої монети, щоб оновити відносні часові блокування, що, можливо, призведе до ненавмисного та катастрофічного зниження безпеки.

Розглянемо, наприклад, що цей вид мініскриптової політики може бути використаний для схеми спадкування або моделі спільного зберігання. Наприклад, власник тримає три ключі, а четвертий передає спадкоємцю або постачальнику послуг ключа відновлення.

Поки вони живі, власник може періодично оновлювати тимчасові блокування, відправляючи монети назад собі, зберігаючи за собою одноосібний контроль над коштами. У разі втрати ключа вони можуть або зачекати, доки закінчиться термін дії першого блокування, або попросити іншого власника ключа допомогти відновити доступ.

Коли вони помирають, спадкоємець отримує односторонній доступ до їх спадщини, як тільки закінчується другий таймлок. однак заморожування гаманця RDTS ризикує завадити власнику вчасно оновити свої монети, роблячи їх вразливими до передчасної крадіжки іншим власником ключа

Наскільки я можу судити, такий вид гаманця Taproot Miniscript можна створити в споживчому програмному забезпеченні сьогодні. наприклад, ось як це виглядає, якщо налаштувати це як кастомний гаманець miniscript у мобільному додатку Nunchuk.