S-a afirmat că OP_IF este întotdeauna inutil în scripturile taproot. Acest lucru este fals. Acest script citat din @mononautical este de fapt mai ieftin dacă este grupat împreună: toate căile de cheltuieli necesită oricum 4 chei publice. După cele 4 OP_CHECKSIGADD, restul scriptului are mai puțin de 32 de octeți, deci este mai ieftin să-l lăsați la pachet. Degruparea, eliminați coada Scriptului care verifică blocajele de timp, dar adăugați 32 de octeți la blocul de control, deoarece Scriptul este acum la adâncimea 1 în loc de 0. Prin urmare, un compilator care optimizează costul cheltuielilor va produce scriptul inclus (adică un arbore cu o singură frunză), deoarece este puțin mai ieftin chiar și în calea principală de cheltuieli (3 din 4). Utilizatorii care optimizează exclusiv pentru confidențialitate vor dori cel mai probabil să o împartă. Cu alte cuvinte, producerea celui mai bun taptree este o problemă de optimizare cu două variabile: costul cheltuielilor și confidențialitatea și, de foarte multe ori, nu puteți optimiza pentru ambele în același timp. M-aș aștepta ca majoritatea utilizatorilor să nu optimizeze absolut exclusiv pentru niciuna dintre variabile și să aleagă mai degrabă un taptree cu un cost destul de bun și o confidențialitate destul de bună. Pentru scenariul pe care @mononautical îl arată aici, un taptree cu doar două frunze ar fi destul de bun: calea principală este doar un simplu 3 din 4 și ar fi folosit pentru majoritatea cheltuielilor, iar restul condițiilor de cheltuieli (posibil grupate într-o singură frunză) sperăm că oricum nu vor atinge niciodată lanțul. Odată ce pui MuSig și FROST în ecuație, există și mai multe variabile: MuSig și FROST pot reduce costurile și pot îmbunătăți confidențialitatea, dar cresc cerințele de interactivitate și complexitatea implementării. Ce vor alege dezvoltatorii și utilizatorii? Nu ştiu! Doar idioții nu au îndoieli.