bip360: disallow depth-zero script trees in P2MR

[conduition]

This changes the validation rules of BIP360 to prevent users from spending script trees of depth zero - those with a single leaf script.

This change is motivated by constructive critiques of P2MR which highlight the regressive use-cases which depth-zero script trees seem to incentivize.

https://groups.google.com/g/bitcoindev/c/p8AVEmAtWdA

This specifically includes disincentivizing the use of a PQ script. With depth-zero script trees in play, users may have incentive to omit a PQ leaf script from their P2MR address to save 32 bytes of witness data when spending with Schnorr.

We also must consider the same incentive for multi-party transaction protocol authors, who may be incentivized to omit a cooperative leaf script to save 32 bytes off the witness of the non-cooperative script.

After this change, P2MR's privacy profile is much more well aligned with that of P2TR: Every user must pay for at least two spending paths anyway, so it encourages everyone to make use of both of them if possible/applicable, whether for cooperative spending path or for a PQ leaf. We thus create ambiguity to on-chain observers: is this a cooperative spend of a multi-party protocol? or just a single-signer wallet with a sibling PQ leaf script?

[conduition]

I have not edited the reference implementations, as they seem to live in third-party repositories.

[jonatack]

cc @cryptoquick @EthanHeilman @Isabelfoxenduke for feedback or sign-off

[EthanHeilman]

@jonatack I like how this incentivizes privacy and the cost of an additional 32-bytes seems worth it. The only drawback I think of is that the script tree has slightly different behavior between P2MR and P2TR. A script tree of depth 0 that works for P2TR would fail for P2MR.

@conduition I do wonder if perhaps it might make sense to have a 0-depth leaf be an OP_SUCCESS rather than a fail. This way we can preserve 0-depth leaf trees as a soft fork mechanism and if someone does put funds into such a tree, they will be able to spend them (as will anyone else).

I had a related idea. From my perspective the main privacy advantage of P2TR that the key spend doesn't use a script and by not using a script you prevent a source of wallet fingerprinting. One could replicate this behavior in P2MR by having the first leaf always be a single public key. If we have alg flagging for public keys, then a single public key would be interpreted as run CHECKSIG_VERIFY on this public key for the alg specified in the flag. This would then make P2MR identical in privacy to P2TR.

All said, I have no strong objection to this change, but I need to catch up on the devlist discussion of this point.