Det har hävdats att OP_IF alltid är onödigt i taproot Scripts. Detta är falskt. Detta skript som citeras från @mononautical är faktiskt billigare om det buntas ihop: alla utgiftsvägar kräver ändå 4 offentliga nycklar. Efter de 4 OP_CHECKSIGADD är resten av skriptet mindre än 32 byte, så det är billigare att lämna det buntat. Uppdelning innebär att du tar bort slutet av skriptet som kontrollerar tidlåsen, men lägger till 32 byte i kontrollblocket eftersom skriptet nu är på djupet 1 i stället för 0. Därför kommer en kompilator som optimerar för utgiftskostnader att skapa det paketerade skriptet (det vill säga ett taptree med ett enda blad), eftersom det är något billigare även i den primära utgiftsvägen (3-av-4). Användare som optimerar uteslutande för integritet kommer med största sannolikhet att vilja dela upp den. Med andra ord, att producera det bästa taptree är ett optimeringsproblem med två variabler: utgiftskostnad och integritet, och mycket ofta kan du inte optimera för båda samtidigt. Jag skulle förvänta mig att de flesta användare inte absolut optimerar för någon av variablerna exklusivt, och snarare väljer ett taptree med ganska bra kostnad och ganska bra integritet. För skriptet som @mononautical visar här skulle ett pålträd med bara två löv vara ganska bra: den primära vägen är bara en enkel 3-av-4 och den skulle användas för de flesta utgifter, och resten av utgiftsvillkoren (möjligen samlade i ett enda pålblad) kommer förhoppningsvis aldrig att träffa kedjan ändå. När du lägger till MuSig och FROST i ekvationen finns det ännu fler variabler: MuSig och FROST kan sänka kostnaderna och förbättra integriteten, men de ökar interaktivitetskraven och implementeringskomplexiteten. Vad kommer utvecklare och användare att välja? Jag vet inte! Det är bara idioter som inte tvivlar.