detta exempel på taproot OP_IF är mycket mer oroande för RDTS-förslaget än jag först insåg. Det är faktiskt en MiniScript plånbokspolicy: tröskning(3,pk(A),pk(B),pk(C),pk(D),äldre(T1),äldre(T2)) vilket betyder "en 3-av-4 multisig, sönderfallande till 2-av-4 efter tiden T1 och 1-av-4 efter tiden T2"

Det finns två relaterade utgifter i nära följd, som var och en utövar ett av TimeLock-utgiftsvillkoren. Exakt den typ av aktivitet du kan förvänta dig av någon som utför slutliga mainnet-tester innan de laddar riktiga pengar i en plånbok som förlitar sig på detta låsskript.

eftersom detta är ett tapscript som använder OP_IF, skulle alla pengar som tas emot av en sådan plånbok efter RDTS-aktivering frysas. Ägaren skulle också inte kunna flytta sina mynt för att uppdatera de relativa tidlåsen, vilket kanske tvingar fram en oavsiktlig och katastrofal minskning av säkerheten.

Tänk till exempel på att den här typen av miniscript-princip kan användas för ett arvsschema eller en samarbetsmodell för vårdnad. Ägaren har t.ex. tre nycklar och överlåter den fjärde till en arvinge eller tjänsteleverantör för återställningsnyckel.

Så länge de är vid liv kan ägaren med jämna mellanrum uppdatera tidlåsen genom att skicka tillbaka mynten till sig själva och behålla ensam kontroll över pengarna. Om de tappar bort en nyckel kan de antingen vänta på att den första TimeLock ska upphöra att gälla eller be den andra nyckelinnehavaren att hjälpa till att återställa åtkomsten.

När de går bort får arvingen ensidig tillgång till sitt arv så snart den andra tidslåset löper ut. Att RDTS fryser plånboken riskerar dock att hindra ägaren från att uppdatera sina mynt i tid, vilket gör dem sårbara för för tidig stöld av den andra nyckelinnehavaren

så vitt jag kan se är den här typen av taproot miniscript-plånbok möjlig att skapa i konsumentprogramvara idag. Så här ser det till exempel ut att ställa in detta som en anpassad miniscript-plånbok i Nunchuks mobilapp.