有人声称在 taproot 脚本中 OP_IF 总是多余的。 这是错误的。 这个来自 @mononautical 的脚本实际上如果捆绑在一起会更便宜：所有的支出路径无论如何都需要 4 个公钥。在 4 个 OP_CHECKSIGADD 之后，脚本的其余部分少于 32 字节，因此将其捆绑在一起更便宜。 解开捆绑，你会移除检查时间锁的脚本尾部，但会因为脚本现在的深度是 1 而不是 0，增加 32 字节到控制块。 因此，一个优化支出成本的编译器 _将_ 生成捆绑的脚本（即，具有单个叶子的 taptree），因为即使在主要支出路径（3-of-4）中，它也稍微便宜。 专门优化隐私的用户很可能会想要拆分它。 换句话说，生成最佳 taptree 是一个有两个变量的优化问题：支出成本和隐私，而通常你不能同时优化这两个变量。我预计大多数用户不会绝对专注于任何一个变量，而是选择一个成本和隐私都相当不错的 taptree。对于 @mononautical 在这里展示的脚本，一个只有两个叶子的 taptree 会相当不错：主要路径只是一个简单的 3-of-4，并且它将用于大多数支出，而其余的支出条件（可能捆绑在一个单一的 tapleaf 中）希望永远不会上链。 一旦你将 MuSig 和 FROST 纳入考虑，还有更多变量：MuSig 和 FROST 可以降低成本并改善隐私，但它们增加了交互要求和实现复杂性。 开发者和用户会选择什么？我不知道！ 只有傻瓜没有疑虑。