On väitetty, että OP_IF on aina tarpeetonta taproot-skripteissä. Tämä on väärin. Tämä @mononautical lainattu skripti on itse asiassa halvempi, jos se niputetaan yhteen: kaikki kulutuspolut vaativat joka tapauksessa 4 julkista avainta. 4 OP_CHECKSIGADD jälkeen loput skriptistä on alle 32 tavua, joten on halvempaa jättää se niputettuna. Eriyttäminen poistaa aikalukkoja tarkistavan komentosarjan hännän, mutta lisää ohjauslohkoon 32 tavua, koska komentosarja on nyt syvyydessä 1 0:n sijaan. Siksi kääntäjä, joka optimoi kulutuskustannuksia varten, tuottaa niputetun skriptin (eli yhden lehden tappuun), koska se on hieman halvempi jopa ensisijaisella kulutuspolulla (3/4). Käyttäjät, jotka optimoivat yksinomaan yksityisyyttä varten, haluavat todennäköisesti jakaa sen. Toisin sanoen parhaan taptreen tuottaminen on optimointiongelma, jossa on kaksi muuttujaa: kulutuskustannukset ja yksityisyys, ja hyvin usein et voi optimoida molemmille samanaikaisesti. Odotan, että useimmat käyttäjät eivät optimoi yksinomaan kumpaankaan muuttujaan, vaan valitsevat mieluummin taptree, jolla on melko hyvät kustannukset ja melko hyvä yksityisyys. Käsikirjoitukselle, jonka @mononautical näyttää tässä, kaksilehtinen tappuu olisi melko hyvä: ensisijainen polku on vain yksinkertainen 3/4 ja sitä käytettäisiin useimpiin menoihin, ja loput kulutusehdot (mahdollisesti niputettuna yhteen tapleafiin) eivät toivottavasti koskaan osu ketjuun joka tapauksessa. Kun yhtälöön lisätään MuSig ja FROST, muuttujia on vielä enemmän: MuSig ja FROST voivat alentaa kustannuksia ja parantaa yksityisyyttä, mutta ne lisäävät interaktiivisuusvaatimuksia ja toteutuksen monimutkaisuutta. Mitä kehittäjät ja käyttäjät valitsevat? Minä en tiedä! Vain idiooteilla ei ole epäilyksiä.