Si è sostenuto che OP_IF sia sempre superfluo negli Script taproot. Questo è falso. Questo Script citato da @mononautical è in realtà più economico se raggruppato: tutti i percorsi di spesa richiedono comunque 4 chiavi pubbliche. Dopo i 4 OP_CHECKSIGADD, il resto dello Script è inferiore a 32 byte, quindi è più conveniente lasciarlo raggruppato. Disaggregando, si rimuove la parte finale dello Script che controlla i timelock, ma si aggiungono 32 byte al blocco di controllo perché lo Script è ora a profondità 1 invece che 0. Pertanto, un compilatore che ottimizza per il costo di spesa _produrrà_ lo Script raggruppato (cioè un taptree con una singola foglia), perché è leggermente più economico anche nel percorso di spesa principale (il 3-di-4). Gli utenti che ottimizzano esclusivamente per la privacy vorranno molto probabilmente separarlo. In altre parole, produrre il miglior taptree è un problema di ottimizzazione con due variabili: costo di spesa e privacy, e molto spesso non si può ottimizzare per entrambe le cose contemporaneamente. Mi aspetto che la maggior parte degli utenti non ottimizzi assolutamente per nessuna delle due variabili in modo esclusivo, e piuttosto scelga un taptree con un costo abbastanza buono e una privacy abbastanza buona. Per lo script che @mononautical mostra qui, un taptree con solo due foglie sarebbe piuttosto buono: il percorso principale è solo un semplice 3-di-4 e verrebbe utilizzato per la maggior parte delle spese, e le restanti condizioni di spesa (possibilmente raggruppate in un'unica tapleaf) sperabilmente non colpiranno mai la catena comunque. Una volta che si introducono MuSig e FROST nell'equazione, ci sono ancora più variabili: MuSig e FROST possono ridurre i costi e migliorare la privacy, ma aumentano i requisiti di interattività e la complessità di implementazione. Cosa sceglieranno sviluppatori e utenti? Non lo so! Solo gli idioti non hanno dubbi.