BCH is better without `MINIMALIF`/`MINIMALBOOL`

[bitjson]

Just creating a topic to leave some notes for future researchers. When I started advocating for P2SH32, I suggested that we consider eliminating boolean malleability:

@bitjson

Eliminate boolean malleability (e.g. MINIMALIF)

I’d like to see boolean malleability resolved for 32-byte P2SH contracts – that would eliminate the remaining known sources of third-party transaction malleability, paying dividends in practical security for average users over the coming decade(s). (This was considered for the Nov. 2019 upgrade, but deemed better to leave for a future upgrade .)

[…]

After experimenting quite a bit with MINIMALIF and a wider MINIMALBOOL (applying the 0/1 restriction to all boolean-accepting operations). I’m now skeptical that either will ever be a good idea for BCH.

In part because we have both introspection and CashTokens now, most of the constructions that seemed to nominally benefit (a few bytes saved here and there, a malleability vector removed) are no longer likely to be very common or useful. E.g. it’s almost always a code smell to provide <0> or <1> in unlocking bytecode, the pattern prioritized by the BTC devs for Lightning Network applications (the driver behind rapid deployment of MINIMALIF on that chain).

Some quick examples:

• Empty unlocking bytecode – A surprising number of contracts can accept empty unlocking bytecode for at least one code path. They instead use transaction introspection to parse information from other inputs/outputs. Jedex (Joint-Execution Decentralized Exchange) demonstrates this for at least one code path in practically every contract.

• OP_DEPTH [OP_IFDUP] OP_IF – rather than switching on naively-pushed values, it’s often possible to switch on the count of stack items provided in unlocking bytecode. This saves a byte vs. many MINIMALIF examples.

• NFT commitments – supporting “non-minimal” OP_IF allows for significant efficiency improvements once you take non-fungible token commitments into consideration. NFTs are not prone to malleability, so the additional functionality is both reliable and useful.

Finally, detached signatures are a comprehensive alternative to piecemeal malleability reduction like MINIMALIF/MINIMALBOOL would be here. They allow us to fully avoid even the need to audit contracts for most malleability-related issues, in addition to other benefits (transaction size reduction, cross-input signature aggregation, etc.)

TLDR: we’re fortunate that MINIMALIF never activated on BCH, recent developments have made it irrelevant/counterproductive.