этот пример taproot OP_IF гораздо более тревожен для предложения RDTS, чем я сначала осознал. это на самом деле политика кошелька miniscript: thresh(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2)) что означает "мультиподпись 3 из 4, уменьшающаяся до 2 из 4 после времени T1 и 1 из 4 после времени T2"

существуют два связанных расхода, происходящих подряд, каждый из которых использует одно из условий временной блокировки. именно такой вид активности вы могли бы ожидать от кого-то, кто проводит финальные тесты основной сети перед загрузкой реальных средств в кошелек, который зависит от этого скрипта блокировки.

поскольку это tapscript с использованием OP_IF, любые средства, полученные таким кошельком после активации RDTS, будут заморожены. владелец также не сможет переместить свои монеты, чтобы обновить относительные временные блокировки, что может привести к непреднамеренному и катастрофическому снижению безопасности.

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

пока они живы, владелец может периодически обновлять таймлоки, отправляя монеты обратно себе, сохраняя единственный контроль над средствами. если они потеряют ключ, они могут либо дождаться истечения первого таймлока, либо попросить другого держателя ключа помочь восстановить доступ.

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

насколько я могу судить, такой кошелек с использованием taproot miniscript можно создать в потребительском программном обеспечении сегодня. например, вот как это выглядит при настройке в качестве пользовательского кошелька miniscript в мобильном приложении Nunchuk.