@SuperTestnet compile_tr_native never emits OP_IF and never falls back to it. Either an IF-free TapTree or an error. No size comparison. The "use OP_IF if it's smaller" behavior is standard compile_tr/best_compilation, not the native path.

"BIP-110 catches almost no spam." That's become the main argument against it. By raw transaction count, it's not entirely wrong. But count is the wrong metric. After decoding every OP_RETURN on Bitcoin for the last 60 days: 91% is now one funded protocol: Alkanes -> Millions of tiny mints BIP-110 won't touch (and shouldn't, that's relay policy's job). But those mints exist because contracts were deployed for them. - Deployment = a WASM binary in a Taproot reveal. 627 of them in 60 days. - Every single one rejected by BIP-110. You don’t stop a metaprotocol by filtering its mints. You stop it at deployment. 👇 blockspaceweekly.substack.co…

For context, for the 110 fork people: Miniscript uses things called fragments. Some of these fragments use op_if, that your fork disables for some reason. A user defines what their wallet should be, for example "a 2-of-5 multisig". Miniscript will output a Bitcoin Script (a wallet basically) that is the best and safest way currently known to do this policy in Bitcoin. Disabling an opcode that is very much a building brick for safe Bitcoin wallets is dumb, but also has a big engineering cost on: - the engineers who build the Miniscript engine - the devs that implemented it, in Core and in multiple libraries like Rust-Miniscript - wallet devs - wallet users who may unknowingly have such a policy. This cost cannot just be denied or ignored by "there is a 2 weeks window" it'll take a lot more than 2 weeks to do (took 3 years to get Miniscript anywhere), and users may be impacted without knowing so. Bip 110 is all about virtue signaling and ignoring real costs on the ecosystem, including potential loss of coins for users who did nothing wrong, just used a good wallet software.