1

Per BIP-341, if you want to create a Taproot output that is only spendable via the script-path spend (and not a key-path spend), you must "pick as internal key a point with unknown discrete logarithm."

This requires using a nothing-up-my-sleeve (NUMS) point as your internal public key which has no valid corresponding private key.

How should I go about choosing such a point? Are there canonical examples to draw from?

Murch
  • 71,155
  • 33
  • 180
  • 600
James O'Beirne
  • 321
  • 8
  • 5
    Does this answer your question? [Taproot - Eliminating Key Path](https://bitcoin.stackexchange.com/questions/99722/taproot-eliminating-key-path) – Michael Folkson Jan 12 '23 at 10:59
  • 1
    Regardless, welcome to StackExchange James :) – Michael Folkson Jan 12 '23 at 11:00
  • Kind of - when I searched "NUMS point" I didn't get anything relevant, so it's probably not indexed for that. – James O'Beirne Jan 12 '23 at 11:00
  • The way to get round that would be to add a "NUMS point" tag. But I don't think that should be a tag, it is pretty specific. You should be searching for Taproot, secp256k1, script tags and hopefully find it through that. Of course the StackExchange search functionality could be improved but that is kind of out of scope for a particular Q&A – Michael Folkson Jan 12 '23 at 11:03
  • 4
    In my experience, the best way to search on Stack Exchange is to use a regular search engine restricted by “site:bitcoin.stackexchange.com”. – Murch Jan 12 '23 at 12:17

1 Answers1

2

In BIP-341, an example NUMS point is given, along with a cautionary note about leaking information:

One example of such a point is H = lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0) which is constructed by taking the hash of the standard uncompressed encoding of the secp256k1 base point G as X coordinate.

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.

For what it's worth, the point as-written is encoded in DER format, so in order to get the corresponding integer you have to remove the first byte (0x02).

James O'Beirne
  • 321
  • 8
  • 1
    Nit: this is not DER format; DER is only used in Bitcoin for ECDSA signatures. This is a public key is SEC compressed encoding (it's still wrong in the BIP though; lift_x just takes an X coordinate as input). – Pieter Wuille Jan 12 '23 at 14:11