Afirmou-se que o OP_IF é sempre desnecessário em Scripts taproot. Isto é falso. Este Script citado por @mononautical é, de fato, mais barato se agrupado: todos os caminhos de gasto requerem 4 chaves públicas de qualquer forma. Após os 4 OP_CHECKSIGADD, o resto do Script tem menos de 32 bytes, portanto é mais barato deixá-lo agrupado. Desagrupar, você remove a parte final do Script que está verificando os bloqueios de tempo, 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 para o custo de gasto _vai_ produzir o Script agrupado (ou seja, uma taptree com uma única folha), porque é ligeiramente mais barato mesmo no caminho de gasto primário (o 3-de-4). Usuários que otimizam exclusivamente para privacidade provavelmente quererão dividi-lo. Em outras palavras, produzir a melhor taptree é um problema de otimização com duas variáveis: custo de gasto e privacidade, e muitas vezes você não pode otimizar para ambas ao mesmo tempo. Eu esperaria que a maioria dos usuários não otimizasse absolutamente para nenhuma variável exclusivamente, e sim escolhesse uma taptree com um custo bastante bom e uma privacidade bastante boa. Para o script que @mononautical mostra aqui, uma taptree com apenas duas folhas seria bastante boa: o caminho primário é apenas um simples 3-de-4 e seria usado para a maioria dos gastos, e as outras condições de gasto (possivelmente agrupadas em uma única tapleaf) espero que nunca atinjam a cadeia de qualquer forma. Uma vez que você coloca 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! Apenas idiotas não têm dúvidas.