Populære emner
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Det har blitt hevdet at OP_IF alltid er unødvendig i taproot Scripts.
Dette er usant.
Dette skriptet sitert fra @mononautical er faktisk billigere hvis det er samlet sammen: alle utgiftsbanene krever 4 offentlige nøkler uansett. Etter de 4 OP_CHECKSIGADD er resten av skriptet mindre enn 32 byte, så det er billigere å la det være samlet.
Ved å skille fra hverandre fjerner du halen på skriptet som kontrollerer tidslåsene, men legger til 32 byte i kontrollblokken fordi skriptet nå er i dybde 1 i stedet for 0.
Derfor _vil_ en kompilator som optimaliserer for utgiftskostnader_ produsere det medfølgende skriptet (det vil si et taptree med et enkelt blad), fordi det er litt billigere selv i den primære utgiftsbanen (3-av-4).
Brukere som optimaliserer utelukkende for personvern vil mest sannsynlig ønske å dele den.
Med andre ord, å produsere det beste tapstreet er et optimaliseringsproblem med to variabler: forbrukskostnader og personvern, og veldig ofte kan du ikke optimalisere for begge samtidig. Jeg forventer at de fleste brukere ikke absolutt optimaliserer for noen av variablene utelukkende, og heller velger et taptree med ganske god pris og ganske godt personvern. For manuset som @mononautical viser her, ville et taptree med bare to blader være ganske bra: den primære banen er bare en enkel 3-av-4, og den vil bli brukt til de fleste utgifter, og resten av utgiftsbetingelsene (muligens samlet i et enkelt tapleaf) vil forhåpentligvis aldri treffe kjeden uansett.
Når du setter MuSig og FROST inn i ligningen, er det enda flere variabler: MuSig og FROST kan redusere kostnadene og forbedre personvernet, men de øker kravene til interaktivitet og implementeringskompleksiteten.
Hva vil utviklere og brukere velge? Jeg vet ikke!
Bare idioter er ikke i tvil.
Topp
Rangering
Favoritter

