Утверждается, что OP_IF всегда ненужен в скриптах taproot. Это неправда. Этот скрипт, процитированный @mononautical, на самом деле дешевле, если его объединить: все пути расходования требуют 4 открытых ключа в любом случае. После 4 OP_CHECKSIGADD остальная часть скрипта меньше 32 байт, поэтому дешевле оставить его объединенным. При разъединении вы удаляете конец скрипта, который проверяет временные замки, но добавляете 32 байта к контрольному блоку, потому что скрипт теперь на глубине 1 вместо 0. Следовательно, компилятор, оптимизирующий стоимость расходования, _будет_ производить объединенный скрипт (то есть taptree с одним листом), потому что это немного дешевле даже в основном пути расходования (3 из 4). Пользователи, оптимизирующие исключительно для конфиденциальности, скорее всего, захотят разделить его. Другими словами, создание лучшего taptree — это задача оптимизации с двумя переменными: стоимость расходования и конфиденциальность, и очень часто вы не можете оптимизировать обе одновременно. Я ожидаю, что большинство пользователей не будут абсолютно оптимизировать ни одну из переменных исключительно, а скорее выберут taptree с довольно хорошей стоимостью и довольно хорошей конфиденциальностью. Для скрипта, который показывает @mononautical, taptree с всего двумя листьями был бы довольно хорош: основной путь — это просто простой 3 из 4, и он будет использоваться для большинства расходов, а остальные условия расходования (возможно, объединенные в одном tapleaf) надеюсь, никогда не попадут в цепь. Как только вы включаете MuSig и FROST в уравнение, появляется еще больше переменных: MuSig и FROST могут снизить затраты и улучшить конфиденциальность, но они увеличивают требования к интерактивности и сложность реализации. Что выберут разработчики и пользователи? Я не знаю! Только идиоты не имеют сомнений.