このタップルートOP_IF例は、RDTSの提案にとって、私が最初に気づいていたよりもはるかに心配です。 これは実際にはミニスクリプトウォレットポリシーです。 スレッシュ(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2)) 「4 つのマルチシグのうち 3 つで、時間 T1 の後に 4 つのうちの 2 つに減衰し、時間 T2 の後に 4 つのうちの 1 つに減衰する」という意味です。

関連する支出が 2 つ連続して存在し、それぞれがタイムロック支出条件の 1 つを実行します。 まさに、このロック スクリプトに依存するウォレットに実際の資金をロードする前に、メインネットの最終テストを実施する人に期待されるようなアクティビティです。

これはOP_IFを使用するTapScriptであるため、RDTSアクティベーション後にそのようなウォレットが受け取った資金は凍結されます。 また、所有者はコインを動かして相対的なタイムロックを更新することもできず、おそらく意図しない壊滅的なセキュリティの低下を余儀なくされるでしょう。

たとえば、この種のミニスクリプト ポリシーが相続スキームまたは共同保管モデルに使用される可能性があることを考えてみましょう。 たとえば、所有者は 3 つのキーを保持し、4 番目のキーを相続人または回復キー サービス プロバイダーに渡します。

それらが生きている限り、所有者はコインを自分自身に送り返すことでタイムロックを定期的に更新し、資金の単独管理を保持できます。 キーを紛失した場合は、最初のタイムロックの有効期限が切れるのを待つか、他のキー所有者にアクセスの復元を手伝ってもらうことができます。

彼らが亡くなると、相続人は 2 回目のタイムロックの有効期限が切れるとすぐに、相続人に一方的に相続財産にアクセスできるようになります。 ただし、RDTS がウォレットを凍結すると、所有者が時間内にコインを更新できなくなり、他のキー所有者による時期尚早の盗難に対して脆弱になるリスクがあります

私の知る限り、この種の Taproot ミニスクリプト ウォレットは、今日の消費者向けソフトウェアで作成することが可能です。 たとえば、これを Nunchuk のモバイル アプリでカスタム ミニスクリプト ウォレットとして設定すると次のようになります。