Tem sido alegado que OP_IF é sempre desnecessário em scripts taproot. Isso é falso. Este script citado de @mononautical é de fato mais barato se agrupado: todos os caminhos de gastos exigem 4 chaves públicas de qualquer maneira. Após os 4 OP_CHECKSIGADD, o restante do Script tem menos de 32 bytes, por isso é mais barato deixá-lo empacotado. Desagregação, você remove a parte final do Script que está verificando os timelocks, mas adiciona 32 bytes ao bloco de controle porque o Script agora está na profundidade 1 em vez de 0. Portanto, um compilador que está otimizando o custo de gastos _irá_ produzir o Script empacotado (ou seja, uma árvore de toque com uma única folha), porque é um pouco mais barato mesmo no caminho de gastos primário (o 3 de 4). Os usuários que otimizam exclusivamente para privacidade provavelmente vão querer dividi-lo. Em outras palavras, produzir o melhor taptree é um problema de otimização com duas variáveis: custo de gastos e privacidade, e muitas vezes você não pode otimizar para ambos ao mesmo tempo. Eu esperaria que a maioria dos usuários não otimizasse absolutamente para nenhuma das variáveis exclusivamente, e preferisse escolher uma árvore de toque com um custo muito bom e uma privacidade muito boa. Para o roteiro que @mononautical mostra aqui, uma árvore de torneira com apenas duas folhas seria muito boa: o caminho principal é apenas um simples 3 de 4 e seria usado para a maioria dos gastos, e o resto das condições de gastos (possivelmente agrupadas em uma única folha principal) espero que nunca atinja a cadeia de qualquer maneira. Depois de colocar MuSig e FROST na equação, há ainda mais variáveis: MuSig e FROST podem reduzir custos e melhorar a privacidade, mas aumentam os requisitos de interatividade e a complexidade da implementação. O que os desenvolvedores e usuários escolherão? Eu não sei! Só os não têm dúvidas.