tämä OP_IF esimerkki on paljon huolestuttavampi RDTS-ehdotuksen kannalta kuin aluksi tajusin. Se on itse asiassa miniscript-lompakkokäytäntö: puinti(3,pk(A),pk(B),pk(C),pk(D),vanhempi(T1),vanhempi(T2)) tarkoittaen "3/4 multisig, joka hajoaa 2/4:ksi ajan T1 jälkeen ja 1/4:ksi ajan T2 jälkeen"

On olemassa kaksi toisiinsa liittyvää kulutusta tiiviisti peräkkäin, ja kumpikin käyttää yhtä aikalukon käyttöehdoista. Juuri sellaista toimintaa, jota voit odottaa henkilöltä, joka suorittaa viimeisiä pääverkkotestejä ennen oikeiden varojen lataamista lompakkoon, joka perustuu tähän lukitusskriptiin.

koska tämä on OP_IF käyttävä tapscript, kaikki tällaiseen lompakkoon RDTS-aktivoinnin jälkeen saadut varat jäädytetään. omistaja ei myöskään pystyisi siirtämään kolikoitaan päivittääkseen suhteellisia aikalukkoja, mikä saattaisi pakottaa tahattoman ja katastrofaalisen turvallisuuden heikkenemisen.

Ajatellaanpa esimerkiksi, että tällaista miniskriptipolitiikkaa voidaan käyttää perintöjärjestelmässä tai yhteistoiminnallisessa huoltajuusmallissa. Esimerkiksi omistajalla on kolme avainta ja neljännen luovuttaa perilliselle tai palautusavainpalvelun tarjoajalle.

Niin kauan kuin ne ovat elossa, omistaja voi ajoittain päivittää aikalukot lähettämällä kolikot takaisin itselleen säilyttäen varojen yksinomaisen hallinnan. Jos hän kadottaa avaimen, hän voi joko odottaa ensimmäisen TimeLockin vanhenemista tai pyytää toista avaimenhaltijaa auttamaan pääsyn palauttamisessa.

Kun he kuolevat, perillinen saa yksipuolisen pääsyn perintöönsä heti, kun toinen aikalukitus umpeutuu. RDTS:n lompakon jäädyttäminen uhkaa kuitenkin estää omistajaa päivittämästä kolikoitaan ajoissa, jolloin ne ovat alttiita toisen avaimenhaltijan ennenaikaisille varkauksille

Sikäli kuin voin sanoa, tällainen Taproot MiniScript -lompakko on mahdollista luoda kuluttajaohjelmistoissa nykyään. esimerkiksi tältä näyttää tämän määrittäminen mukautetuksi miniscript-lompakoksi Nunchukin mobiilisovelluksessa.