On a affirmé que OP_IF est toujours inutile dans les scripts taproot. C'est faux. Ce script cité par @mononautical est en fait moins cher s'il est regroupé : tous les chemins de dépense nécessitent de toute façon 4 clés publiques. Après les 4 OP_CHECKSIGADD, le reste du script fait moins de 32 octets, donc il est moins cher de le laisser regroupé. En le dégroupant, vous retirez la fin du script qui vérifie les délais, mais vous ajoutez 32 octets au bloc de contrôle car le script est maintenant à une profondeur de 1 au lieu de 0. Par conséquent, un compilateur qui optimise pour le coût de dépense _produira_ le script regroupé (c'est-à-dire un taptree avec une seule feuille), car c'est légèrement moins cher même dans le chemin de dépense principal (le 3 sur 4). Les utilisateurs qui optimisent exclusivement pour la confidentialité voudront très probablement le diviser. En d'autres termes, produire le meilleur taptree est un problème d'optimisation avec deux variables : le coût de dépense et la confidentialité, et très souvent, vous ne pouvez pas optimiser pour les deux en même temps. Je m'attendrais à ce que la plupart des utilisateurs ne cherchent pas à optimiser absolument pour l'une ou l'autre variable exclusivement, mais choisissent plutôt un taptree avec un coût assez bon et une confidentialité assez bonne. Pour le script que @mononautical montre ici, un taptree avec juste deux feuilles serait assez bon : le chemin principal est juste un simple 3 sur 4 et il serait utilisé pour la plupart des dépenses, et le reste des conditions de dépense (peut-être regroupées dans une seule tapleaf) ne frappera de toute façon jamais la chaîne. Une fois que vous mettez MuSig et FROST dans l'équation, il y a encore plus de variables : MuSig et FROST peuvent réduire les coûts et améliorer la confidentialité, mais ils augmentent les exigences d'interactivité et la complexité de mise en œuvre. Que choisiront les développeurs et les utilisateurs ? Je ne sais pas ! Seuls les idiots n'ont aucun doute.