Стверджується, що OP_IF завжди непотрібне в taproot скриптах. Це неправда. Цей скрипт, процитований з @mononautical, насправді дешевший, якщо його об'єднати разом: всі шляхи витрат все одно вимагають 4 публічних ключа. Після 4 OP_CHECKSIGADD решта Script становить менше 32 байт, тому дешевше залишити його в комплекті. При відокремленні ви видаляєте хвіст скрипта, який перевіряє блокування часу, але додаєте 32 байти до блоку керування, оскільки тепер скрипт знаходиться на глибині 1 замість 0. Таким чином, компілятор, який оптимізує витрати на витрати, _буде_ виробляти пакетний скрипт (тобто тап-дерево з одним листом), тому що він трохи дешевший навіть у основному шляху витрат (3 з 4). Користувачі, які оптимізуються виключно для конфіденційності, швидше за все, захочуть його розділити. Іншими словами, виробництво найкращого дерева – це проблема оптимізації з двома змінними: витратними витратами та конфіденційністю, і дуже часто ви не можете оптимізувати для обох одночасно. Я б очікував, що більшість користувачів не будуть абсолютно оптимізуватися виключно для будь-якої змінної, а скоріше виберуть taptree з досить хорошою вартістю та досить хорошою конфіденційністю. Для скрипту, який @mononautical показує тут, таптрі лише з двома листками було б досить непоганим: основний шлях - це просто 3 з 4, і він буде використовуватися для більшості витрат, а решта умов витрат (можливо, об'єднані в один лист натискання), сподіваюся, ніколи не потраплять у ланцюжок у будь-якому випадку. Як тільки ви помістите MuSig і FROST в рівняння, з'явиться ще більше змінних: MuSig і FROST можуть знизити витрати і поліпшити конфіденційність, але вони підвищують вимоги до інтерактивності і складність реалізації. Що виберуть розробники та користувачі? Я не знаю! Тільки у ідіотів немає сумнівів.