NUMS_UNSPENDABLE_KEY_HEX is not supposed to be used as is (privacy concerns)

[tvpeter]

I believe technically the NUMS_UNSPENDABLE_KEY_HEX is not supposed to be used as is (privacy concerns), though for now it's fine. Per BIP-0431, should add an issue to do the following:

"In order to avoid leaking the information that key path spending is not possible it is recommended to pick a fresh integer r in the range 0...n-1 uniformly at random and use H + rG as internal key. It is possible to prove that this internal key does not have a known discrete logarithm with respect to G by revealing r to a verifier who can then reconstruct how the internal key was created."

Originally posted by @notmandatory in #208 (comment)

[va-an]

If this is planned to be done not in 2.0.0, but in a subsequent version, then please assign this to me.

[va-an]

Should the compile command optionally return the randomness value r for Taproot descriptors?

For Taproot descriptor compilation, the approach is to generate a randomized unspendable internal key using H + rG where:

• H = NUMS point (constant)
• r = random scalar
• G = generator point

Should we expose r to allow independent verification of the descriptor construction (verifying internal_key = H + rG)?

Implementation options:

1. Never return r - simpler UX, cleaner output
2. Always return r - maximum transparency, may clutter output
3. Optional flag --return-randomness - users opt-in when needed

Which approach do you prefer?

[notmandatory]

Since the bdk-cli tool is primarily used for testing and education I'd prefer option 2, to always output it when creating a descriptor that uses one. It may also be useful to add a new CLI command to verify the NUMS unspendable key for a descriptor given the r value.