bip360: depth-zero script trees should be anyone-can-spend

[conduition]

This PR changes the validation rules of BIP360 to prevent users from spending add an auto-success path for script trees of depth zero - those with a single leaf script. By doing so, we discourage use of depth-zero script trees: anyone who uses them will lose their money to miners.

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

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

Specifically, depth-zero script trees disincentivize 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 P2MR 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?

If depth-zero script trees are anyone-can-spend, this still leaves it open to future use in a later soft-fork. For example, if we someday have enough confidence to deploy isogenies, we can use taproot-style key tweaking with isogenies to hide a commitment to a script tree inside an isogeny-based pubkey, and put that pubkey in the P2MR "script" stack element, allowing a kind of key-spending with isogenies with a hidden script tree fallback. Other options abound.

Thanks to @EthanHeilman for his suggestion to make this change reversible through an auto-success path. The first version of this PR implemented a straight-up ban on depth-zero script trees.

[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.

[conduition]

perhaps it might make sense to have a 0-depth leaf be an OP_SUCCESS rather than a fail

Brilliant idea. This leaves it much more open-ended so P2MR could potentially be reused for something else exciting in the future, e.g. isogeny key tweaking, something with lattices, etc. I'll see about making this change in the next few days

One could replicate this behavior in P2MR by having the first leaf always be a single public key

Could work for today, but then what do we do after Q-day? With Schnorr we can do multisig, threshold, etc, so having a single-pubkey as the default (mandated) spend path is reasonable, but not so with hash-based sigs where you'd need an explicit multisignature script, threshold script, etc.

[EthanHeilman]

Could work for today, but then what do we do after Q-day? With Schnorr we can do multisig, threshold, etc, so having a single-pubkey as the default (mandated) spend path is reasonable, but not so with hash-based sigs where you'd need an explicit multisignature script, threshold script, etc.

You could do:

• Single pubkey in leaf means CHECKSIG
• Multiple pubkey in leaf means MULTISIG
• Multiple pubkey and number in leaf means MULTISIG of N

I'm not big fan of inferring the script based on number of public keys because you leak if something is a multisig or not. Better to do a script like you are proposing.

We could enforce single pubkey with the expectation that we will figure out a way to do aggregation for any signature algorithm we add.

[conduition]

I applied Ethan's idea to make depth-zero script trees an anyone-can-spend path and updated the PR description/title. Note the auto-success path occurs after the P2MR commitment opening is validated (i.e. after validating $k_m = q$), so it cannot be gamed by a spender.

I like how this incentivizes privacy and the cost of an additional 32-bytes seems worth it

Small note on this: adding a minimum depth won't affect witness size for a majority of P2MR use-cases because almost everyone using P2MR will be doing so for quantum-security. I think the most common use-case this might affect would be addresses who want no standalone EC keys in their script tree at all, e.g. a pure PQC script, or an EC+PQC hybrid script. But for such use-cases, 32 bytes of extra witness data would be a relatively minor handicap due to the size of most PQ signatures.

[cryptoquick]

Good, thoughtful changes. Happy to also make sure they are supported in P2MRv2 and also reflected in Rust and Python test vectors.

[jonatack]

Has m been defined before this line?

(I do see a definition in line 296 below: "where m is the depth of the leaf script.")

[conduition]

Yep, up at L242:

The last stack element is called the control block ''c'', and must have length ''1 + 32 * m'', for a value of ''m'' that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.

[conduition]

I could make it more explicit:

Suggested change

	** If ''m = 0'', succeed immediately.
	** If ''len(c) = 1'', succeed immediately.

[jonatack]

Thanks! I overlooked it.

[jonatack]

I think the line containing the following would be clearer if it was a Let statement (or 2 Let statements for c and m on separate lines if m is kept). But it's only a nit.

The last stack element is called the control block ''c'', and must have length ''1 + 32 * m'', for a value of ''m'' that is an integer between 0 and 128, inclusive.

[jonatack]

Add a changelog entry? (If you do, update also the Version header at the top.)

[conduition]

oh thanks, forgot that. Now done.

[jonatack]

Thanks for adding the changelog (and updating the PR title/description).