dette taproot OP_IF eksempel er mye mer bekymringsfullt for RDTS-forslaget enn jeg først var klar over. Det er faktisk en MiniScript-lommebokpolicy: tresk (3, pk (A), pk (B), pk (C), pk (D), eldre (T1), eldre (T2)) som betyr "en 3-av-4 multisig, som henfaller til 2-av-4 etter tid T1, og 1-av-4 etter tid T2"

Det er to relaterte utgifter i tett rekkefølge, som hver utøver en av tidslås-utgiftsbetingelsene. Akkurat den typen aktivitet du kan forvente av noen som utfører endelige mainnet-tester før du laster ekte penger inn i en lommebok som er avhengig av dette låseskriptet.

siden dette er et tapscript som bruker OP_IF, vil alle midler mottatt av en slik lommebok etter RDTS-aktivering bli frosset. eieren ville heller ikke være i stand til å flytte myntene sine for å oppdatere de relative tidslåsene, noe som kanskje ville tvinge frem en utilsiktet og katastrofal reduksjon i sikkerheten.

Tenk for eksempel på at denne typen miniskriptpolicy kan brukes for en arveordning eller samarbeidsforvaringsmodell. eieren har for eksempel tre nøkler, og gir den fjerde til en arving eller leverandør av gjenopprettingsnøkkel.

Så lenge de er i live, kan eieren med jevne mellomrom oppdatere tidslåsene ved å sende myntene tilbake til seg selv, og beholde enekontroll over midlene. Hvis de mister en nøkkel, kan de enten vente til den første TimeLock utløper, eller be den andre nøkkelinnehaveren om å hjelpe til med å gjenopprette tilgangen.

Når de går bort, får arvingen ensidig tilgang til arven så snart den andre tidssperren utløper. RDTS fryser lommeboken risikerer imidlertid å hindre eieren i å oppdatere myntene sine i tide, noe som gjør dem sårbare for for tidlig tyveri av den andre nøkkelinnehaveren

så vidt jeg kan se, er denne typen taproot miniscript-lommebok mulig å lage i forbrukerprogramvare i dag. for eksempel, her er hvordan det ser ut å sette opp dette som en tilpasset miniscript-lommebok i Nunchuks mobilapp.