這個 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 錢包的樣子。