I am working on CTV, which has cases where it's plausible you'd want a taproot tree with a NUMS point.
The need for NUMS points is a little bit annoying. There are a few reasons you would want to use them instead of multisig:
1) Cheaper to verify/create.
If I have a protocol with 1000 people in it, if I add a multisig N of N to verify I need a key for all those people, and the probability of use seems low.
I then also need to prove to each person in the tree that their key is present. My memory on MuSig is a bit rusty, but I think they key aggregation requires sending all the public keys and re-computing. (Maybe you can compress this to O(log n) using a Merkle tree for the tweak L?)
Further, these keys can't just be the addresses provided for those 1000 people, as if those addresses are themselves N of Ns or scripts it gets complicated, fast (and potentially broken). Instead we should ask that each participant give us a list of keys to include in the top-level. We'd also want each participant to provide
two signatures with that key of some piece of non-txn data (so as to prove it itself wasn't a NUMS point -- otherwise may as well skip this all and just use a top-level nums point).
2) Auditable.
If I set up an inheritance scheme, like an annuity or something, and the IRS wants me to pay taxes on what I've received, adverse inference will tell them to assume that my parent gave me a secret get all the money path and this is a tax dodge. With a NUMS point, heirs can prove there was no top-level N of N.
3) I simply don't want to spend it without a script condition, e.g., timelock.
Now, assuming you do want a NUMS, there is basically 4 ways to make one (that I could think of):
1) Public NUMS -- this is a constant, HashToCurve("I am a NUMS Point"). Anyone scanning the chain can see spends are using this constant. Hopefully everyone uses the same constant (or everyone uses 2,3,4) so that "what type of NUMS you are using" isn't a new fingerprint.
2) Moslty Public NUMS -- I take the hash of some public data (like maybe the txid) on some well defined protocol, and use that. Anyone scanning the chain and doing an EC operation per-txid can see I'm using a constant -- maybe my HashToCurve takes 10 seconds (perhaps through a VDF to make it extra annoying for anyone who hasn't been sent the shortcut), but in practice it's no better than 1.
3) Interactive NUMS -- I swap H(Rx), H(Ry) with the other participant and then NUMS with H(Rx || Ry). This is essentially equivalent to using a MuSig key setup where one person's key is a NUMS. Now no one passively scanning can see that it's NUMS, but I can prove to an auditor later.
4) 1/2 RTT Async-Interactive NUMS -- I take some public salt -- say the txid T, and hash it with a piece of random data R and then HashToCurve(T || R)... I think this is secure? Not clear the txid adds any security. Now I can prove to you that the hash was based on the txid, but I've blinded it with R to stop passive observers. But I also need ot send you data out of band for R (but I already had to do this for Taproot maybe?)
The downsides with 3/4 is that if you lose your setup, you lose your ability to spend/prove it's private (maybe can generate R from a seed?). So better hold on to those tightly! Or use a public NUMS.
Only 3,4 provide any "real" privacy benefit and at a small hit to likelihood of losing funds (more non-deterministic data to store). I guess the question becomes how likely are we to have support for generating a bunch of NUMS points?
Comparing with this proposal which removes the NUMS requirement:
1) NUMS/Taproot anonymity set *until* spend, MAST set after spend
2) No complexity around NUMS generation/storage
3) If people don't have ecosystem-wide consistent NUMS practices, leads to additional privacy leak v.s. bare MAST which would be equivalent to case 1 (Public NUMS)
4) Slightly less chain overhead (32 bytes/8 vbytes).
5) Slightly faster chain validation (EC Point tweak is what like 10,000 - 100,000 times slower than a hash?)
Matt raises a interesting point in the other thread, which is that if we put the option for a more private NUMS thing, someone will eventually write software for it. But that seems to be irrespective of if we make no-NUMS an option for bare MAST spends.
Overall I think this is a reasonable proposal. It effectively only introduces bare MAST to prevent the case where people are using a few different Public NUMS leaking metadata by putting incentive to use the same one -- none. Using a private NUMS is unaffected incentive wise as it's essentially just paying a bit more to be in the larger anonymity set. I think it makes some class of users better off, and no one else worse off, so this change seems Pareto.
Thus I'm in favor of adding a rule like this.
I think reasonable alternative responses to accepting this proposed change would be to:
1) Add a BIP for a standard Public NUMS Point exported through secp256k1 to head off people defining their own point.
2) Add a discounting rule if the point P is the Public NUMS that discounts the extra weight somehow.