Se ha afirmado que OP_IF siempre es innecesario en los scripts de root. Esto es falso. Este script citado de @mononautical es de hecho más barato si se agrupa: todas las rutas de gasto requieren 4 claves públicas de todos modos. Después de los 4 OP_CHECKSIGADD, el resto del Script tiene menos de 32 bytes, por lo que es más barato dejarlo empaquetado. Al desagregar, se quita la cola del script que está comprobando los bloqueos de tiempo, pero se agregan 32 bytes al bloque de control porque el script ahora está en profundidad 1 en lugar de 0. Por lo tanto, un compilador que está optimizando para gastar el costo _producirá_ el Script agrupado (es decir, un árbol de grifo con una sola hoja), porque es un poco más barato incluso en la ruta de gasto principal (el 3 de 4). Lo más probable es que los usuarios que optimicen exclusivamente la privacidad quieran dividirla. En otras palabras, producir el mejor árbol de grifo es un problema de optimización con dos variables: costo de gasto y privacidad, y muy a menudo no se puede optimizar para ambos al mismo tiempo. Esperaría que la mayoría de los usuarios no optimicen absolutamente ninguna de las variables exclusivamente, sino que elijan un árbol de grifo con un costo bastante bueno y una privacidad bastante buena. Para el script que @mononautical muestra aquí, un árbol de grifo con solo dos hojas sería bastante bueno: la ruta principal es solo un simple 3 de 4 y se usaría para la mayoría de los gastos, y el resto de las condiciones de gasto (posiblemente agrupadas en una sola hoja de derivación) con suerte nunca llegarán a la cadena de todos modos. Una vez que se ponen MuSig y FROST en la ecuación, hay aún más variables: MuSig y FROST pueden reducir los costes y mejorar la privacidad, pero aumentan los requisitos de interactividad y la complejidad de la implementación. ¿Qué elegirán los desarrolladores y usuarios? ¡No sé! Solo los idiotas no tienen dudas.