tento příklad taproot OP_IF je pro návrh RDTS mnohem znepokojivější, než jsem si původně uvědomil. Je to vlastně politika peněženky Miniscript: thresh(3,pk(A),pk(B),pk(C),pk(D),older(T1),older(T2)) což znamená "multisig 3 ze 4, rozpadající se na 2 ze 4 po čase T1 a 1 ze 4 po čase T2"

Existují dvě související výdaje v těsném sledu, z nichž každá uplatňuje jednu z podmínek výdajů časového zámku. Přesně takovou aktivitu byste mohli očekávat od někoho, kdo provádí závěrečné testy mainnetu před vložením skutečných prostředků do peněženky, která se spoléhá na tento uzamykací skript.

protože se jedná o tapscript využívající OP_IF, veškeré prostředky přijaté takovou peněženkou po aktivaci RDTS by byly zmrazeny. Majitel by také nemohl přesunout své mince, aby obnovil relativní časové zámky, což by si možná vynutilo nezamýšlené a katastrofální snížení bezpečnosti.

Zvažte například, že tento druh zásad minimálního skriptu může být použit pro schéma dědičnosti nebo model společné péče. např. vlastník drží tři klíče a čtvrtý předá dědici nebo poskytovateli služeb obnovovacích klíčů.

Dokud jsou naživu, může majitel pravidelně obnovovat časové zámky tím, že pošle mince zpět k sobě, přičemž si ponechá výhradní kontrolu nad prostředky. Pokud ztratí klíč, mohou buď počkat na vypršení platnosti prvního časového zámku, nebo požádat druhého držitele klíče, aby jim pomohl obnovit přístup.

Když zemřou, dědic získá jednostranný přístup ke svému dědictví, jakmile vyprší druhý časový zámek. zamrznutí peněženky RDTS však riskuje, že majiteli zabrání včas obnovit své mince, takže jsou zranitelné vůči předčasné krádeži druhým držitelem klíčů

pokud mohu říci, tento druh peněženky Taproot Miniscript je dnes možné vytvořit ve spotřebitelském softwaru. zde je například to, jak to vypadá při nastavení jako vlastní peněženky Miniscript v mobilní aplikaci Nunchuk.