Es wurde behauptet, dass OP_IF in Taproot-Skripten immer unnötig ist. Das ist falsch. Dieses Skript, zitiert von @mononautical, ist in der Tat günstiger, wenn es zusammengefasst wird: Alle Ausgabepfade erfordern ohnehin 4 öffentliche Schlüssel. Nach den 4 OP_CHECKSIGADD ist der Rest des Skripts weniger als 32 Bytes, daher ist es günstiger, es zusammengefasst zu lassen. Beim Entpacken entfernt man den Teil des Skripts, der die Zeitbeschränkungen überprüft, fügt jedoch 32 Bytes zum Kontrollblock hinzu, da das Skript jetzt eine Tiefe von 1 anstelle von 0 hat. Daher wird ein Compiler, der auf die Ausgabekosten optimiert, _das_ gebündelte Skript erzeugen (das heißt, einen Taptree mit einem einzigen Blatt), da es selbst im primären Ausgabepfad (dem 3-von-4) etwas günstiger ist. Benutzer, die ausschließlich auf Privatsphäre optimieren, werden es höchstwahrscheinlich aufteilen wollen. Mit anderen Worten, die Erstellung des besten Taptrees ist ein Optimierungsproblem mit zwei Variablen: Ausgabekosten und Privatsphäre, und sehr oft kann man nicht gleichzeitig für beide optimieren. Ich würde erwarten, dass die meisten Benutzer nicht absolut für eine der Variablen optimieren und stattdessen einen Taptree mit ziemlich guten Kosten und ziemlich guter Privatsphäre wählen. Für das Skript, das @mononautical hier zeigt, wäre ein Taptree mit nur zwei Blättern ziemlich gut: Der primäre Pfad ist nur ein einfaches 3-von-4 und würde für die meisten Ausgaben verwendet werden, und die restlichen Ausgabebedingungen (möglicherweise in einem einzigen Tapleaf gebündelt) werden hoffentlich ohnehin nie die Kette erreichen. Sobald man MuSig und FROST in die Gleichung einbezieht, gibt es noch mehr Variablen: MuSig und FROST können die Kosten senken und die Privatsphäre verbessern, erhöhen jedoch die Interaktivitätsanforderungen und die Implementierungskomplexität. Was werden Entwickler und Benutzer wählen? Ich weiß es nicht! Nur Idioten haben keine Zweifel.