Se ha afirmado que OP_IF es siempre innecesario en los Scripts de taproot. Esto es falso. Este Script citado de @mononautical es de hecho más barato si se agrupa: todos los caminos de gasto requieren 4 claves públicas de todos modos. Después de los 4 OP_CHECKSIGADD, el resto del Script es menos de 32 bytes, por lo que es más barato dejarlo agrupado. Al desagrupar, eliminas la parte final del Script que está comprobando los bloqueos temporales, pero añades 32 bytes al bloque de control porque el Script ahora está a una profundidad de 1 en lugar de 0. Por lo tanto, un compilador que esté optimizando para el costo de gasto _producirá_ el Script agrupado (es decir, un taptree con una sola hoja), porque es ligeramente más barato incluso en el camino de gasto principal (el 3 de 4). Los usuarios que optimizan exclusivamente por privacidad probablemente querrán dividirlo. En otras palabras, producir el mejor taptree es un problema de optimización con dos variables: costo de gasto y privacidad, y muy a menudo no puedes optimizar ambas al mismo tiempo. Esperaría que la mayoría de los usuarios no optimicen absolutamente para ninguna variable exclusivamente, y más bien elijan un taptree con un costo bastante bueno y una privacidad bastante buena. Para el script que @mononautical muestra aquí, un taptree con solo dos hojas sería bastante bueno: el camino principal es solo un simple 3 de 4 y se utilizaría para la mayoría de los gastos, y las demás condiciones de gasto (posiblemente agrupadas en una sola tapleaf) con suerte nunca llegarán a la cadena de todos modos. Una vez que introduces MuSig y FROST en la ecuación, hay aún más variables: MuSig y FROST pueden reducir costos y mejorar la privacidad, pero aumentan los requisitos de interactividad y la complejidad de implementación. ¿Qué elegirán los desarrolladores y los usuarios? ¡No lo sé! Solo los idiotas no tienen dudas.