bu ana kök OP_IF örneği, RDTS teklifi için ilk fark ettiğimden çok daha endişe verici. Aslında bu bir Miniscript cüzdan politikasıdır: harman(3,pk(A),pk(B),pk(C),pk(D),eski(T1),eski(T2)) "T1 zamanından sonra 4'te 2'ye ve T2 zamanından sonra 4'te 1'e azalan 3/4 çoklu imza" anlamına gelir

Her biri zaman kilidi harcama koşullarından birini uygulayan, birbiriyle yakından ilişkili iki harcama vardır. tam olarak, bu kilitleme komut dosyasına dayanan bir cüzdana gerçek para yüklemeden önce son ana ağ testleri yapan birinden bekleyebileceğiniz türden bir etkinlik.

bu, OP_IF kullanan bir tapscript olduğundan, RDTS aktivasyonundan sonra böyle bir cüzdan tarafından alınan tüm fonlar dondurulacaktır. Sahibi ayrıca göreceli zaman kilitlerini yenilemek için madeni paralarını hareket ettiremeyecek ve belki de güvenlikte istenmeyen ve feci bir azalmaya neden olacaktır.

Örneğin, bu tür bir MiniScript politikasının bir miras planı veya işbirlikçi saklama modeli için kullanılabileceğini düşünün. Örneğin, sahibi üç anahtara sahiptir ve dördüncüyü bir mirasçıya veya kurtarma anahtarı servis sağlayıcısına devreder.

Hayatta oldukları sürece, sahibi coinleri kendisine geri göndererek zaman kilitlerini periyodik olarak yenileyebilir ve fonların tek kontrolünü elinde tutabilir. Bir anahtarı kaybederlerse, ilk zaman kilidinin süresinin dolmasını bekleyebilir veya diğer anahtar sahibinden erişimi geri yüklemesine yardım etmesini isteyebilirler.

vefat ettiklerinde, mirasçı, ikinci zaman kilidi sona erer ermez mirasına tek taraflı erişim elde eder. ancak RDTS'nin cüzdanı dondurması, sahibinin madeni paralarını zamanında yenilemesini engelleme riski taşır ve onları diğer anahtar sahibi tarafından erken çalınmaya karşı savunmasız bırakır

anlayabildiğim kadarıyla, bu tür bir taproot miniscript cüzdanı bugün tüketici yazılımlarında oluşturmak mümkün. örneğin, bunu Nunchuk'un mobil uygulamasında özel bir miniscript cüzdan olarak ayarlamak şöyle görünüyor.