bitcoindevkit
NUMS_UNSPENDABLE_KEY_HEX is not supposed to be used as is (privacy concerns)
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 https://github.com/bitcoindevkit/bdk-cli/pull/208#discussion_r2330503782
If this is planned to be done not in 2.0.0, but in a subsequent version, then please assign this to me.
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:
- Never return r - simpler UX, cleaner output
- Always return r - maximum transparency, may clutter output
- Optional flag --return-randomness - users opt-in when needed
Which approach do you prefer?
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.
