这个 taproot OP_IF 示例对 RDTS 提案的影响比我最初意识到的要严重得多。 它实际上是一个 miniscript 钱包策略： thresh(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2)) 这意味着 "一个 3-of-4 多重签名，在时间 T1 后衰减为 2-of-4，在时间 T2 后衰减为 1-of-4"

有两个相关的支出紧密相连，每个都执行了一个时间锁支出条件。 这正是你可能期望从某个在将真实资金加载到依赖于此锁定脚本的钱包之前进行最终主网测试的人身上看到的活动。

由于这是一个使用 OP_IF 的 tapscript，因此在 RDTS 激活后，任何收到的资金将被冻结。 所有者也将无法移动他们的币以刷新相对时间锁，这可能会导致意外且灾难性的安全性降低。

例如，可以考虑这种 miniscript 策略可能用于遗产计划或协作保管模型。 例如，所有者持有三把钥匙，并将第四把钥匙交给继承人或恢复密钥服务提供商。

只要他们还活着，所有者就可以通过将硬币发送回自己，定期刷新时间锁，从而保持对资金的唯一控制。 如果他们丢失了密钥，他们可以选择等待第一个时间锁到期，或者请求其他密钥持有者帮助恢复访问权限。

当他们去世时，继承人在第二个时间锁到期后可以单方面获得他们的遗产。 然而，RDTS 冻结钱包的风险在于可能会阻止所有者及时刷新他们的币，使他们容易受到其他密钥持有者的提前盗窃。

据我所知，这种 taproot miniscript 钱包在今天的消费软件中是可以创建的。 例如，在 Nunchuk 的移动应用中设置为自定义 miniscript 钱包的样子如下。