Tvrdí se, že OP_IF je v taproot skriptech vždy zbytečné. To není pravda. Tento skript citovaný z @mononautical je ve skutečnosti levnější, pokud je spojen dohromady: všechny cesty útraty stejně vyžadují 4 veřejné klíče. Po 4 OP_CHECKSIGADD má zbytek skriptu méně než 32 bajtů, takže je levnější jej nechat přibalený. Oddělením odstraníte konec skriptu, který kontroluje časové zámky, ale přidáte 32 bajtů do řídicího bloku, protože skript je nyní v hloubce 1 místo 0. Proto kompilátor, který je optimalizován pro výdajové náklady, _bude_ vytvářet přibalený skript (tj. taptree s jedním listem), protože je o něco levnější i v primární cestě výdajů (3 ze 4). Uživatelé optimalizující výhradně pro ochranu soukromí jej s největší pravděpodobností budou chtít rozdělit. Jinými slovy, vytvoření nejlepšího taptree je optimalizační problém se dvěma proměnnými: výdajovými náklady a soukromím, a velmi často nemůžete optimalizovat pro obě současně. Očekával bych, že většina uživatelů nebude absolutně optimalizovat výhradně pro jednu z proměnných a raději si vybere taptree s docela dobrou cenou a docela dobrým soukromím. Pro skript, který zde ukazuje @mononautical, by byl taptree s pouhými dvěma listy docela dobrý: primární cesta je jen jednoduchá 3 ze 4 a byla by použita pro většinu výdajů a zbytek výdajových podmínek (možná zabalených do jednoho tapleafu) doufejme, že se stejně nikdy nedostane do řetězce. Jakmile do rovnice zařadíte MuSig a FROST, existuje ještě více proměnných: MuSig a FROST mohou snížit náklady a zlepšit soukromí, ale zvyšují požadavky na interaktivitu a složitost implementace. Co si vývojáři a uživatelé vyberou? Nevím! Jen idioti nemají žádné pochybnosti.