Er is beweerd dat OP_IF altijd onnodig is in taproot Scripts. Dit is onjuist. Dit Script, geciteerd van @mononautical, is in feite goedkoper als het samen wordt gebundeld: alle uitgavenpaden vereisen toch 4 publieke sleutels. Na de 4 OP_CHECKSIGADD is de rest van het Script minder dan 32 bytes, dus het is goedkoper om het gebundeld te laten. Bij het ontbundelen verwijder je de staart van het Script dat de timelocks controleert, maar voeg je 32 bytes toe aan het controleblok omdat het Script nu op diepte 1 in plaats van 0 is. Daarom zal een compiler die optimaliseert voor uitgavenkosten _de_ gebundelde Script produceren (dat wil zeggen, een taptree met een enkele blad), omdat het iets goedkoper is, zelfs in het primaire uitgavenpad (de 3-uit-4). Gebruikers die exclusief optimaliseren voor privacy willen het waarschijnlijk splitsen. Met andere woorden, het produceren van de beste taptree is een optimalisatieprobleem met twee variabelen: uitgavenkosten en privacy, en heel vaak kun je niet voor beide tegelijkertijd optimaliseren. Ik verwacht dat de meeste gebruikers niet absoluut voor een van beide variabelen exclusief zullen optimaliseren, en eerder kiezen voor een taptree met een vrij goede kost en vrij goede privacy. Voor het script dat @mononautical hier toont, zou een taptree met slechts twee bladeren vrij goed zijn: het primaire pad is gewoon een eenvoudige 3-uit-4 en zou voor de meeste uitgaven worden gebruikt, en de rest van de uitgavevoorwaarden (mogelijk gebundeld in een enkele tapleaf) zullen hopelijk nooit de keten raken. Zodra je MuSig en FROST in de vergelijking meerekent, zijn er nog meer variabelen: MuSig en FROST kunnen de kosten verlagen en de privacy verbeteren, maar ze verhogen de interactiviteitsvereisten en de implementatiecomplexiteit. Wat zullen ontwikkelaars en gebruikers kiezen? Ik weet het niet! Alleen idioten hebben geen twijfels.