Glossary / Addresses & keys
NUMS point
- What is a NUMS point?
- A NUMS point is a public key nobody holds the private key for, used as a taproot internal key when the cooperative spending path is meant to be impossible.
Specified in BIP-341.
Nothing Up My Sleeve is the property: the point comes from a public, repeatable recipe, so nobody can claim a secret key for it. BIP-341 publishes one such point, the x coordinate 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0, produced by hashing the standard uncompressed encoding of the secp256k1 base point G. For a wallet, that is how a taproot output becomes script-only: spendable through its tree of conditions and nothing else.
How it works
A NUMS point starts life as a hash, not as a key.
An ordinary public key is the generator G multiplied by a secret number, and whoever picked that number can sign. A NUMS point is built backwards: take a fixed public string, hash it, and read the 32-byte digest as an x coordinate. The example in BIP-341 hashes the standard uncompressed encoding of G itself, which leaves the author no freedom to rig the input. Lifting that value to a curve point gives a public key valid in every respect but one: signing for it would mean solving a discrete logarithm, and BIP-341 names 1 in 2 to the 128 as the design's security bound.
Taproot supplies the rest. A taproot output key is the internal key P shifted along the curve by a tweak committing to the merkle root of the script tree: BIP-341 sets t = hash_TapTweak(p || merkle_root), then Q = P + int(t)G. Signing for Q on the key path needs the private key behind P, so when P is a NUMS point that path is shut and the script path is the only way in. Such a spend reveals one leaf plus a control block of 33 + 32m bytes, where m is the number of sibling hashes, capped by BIP-341 at 128.
One leak is worth knowing. A well-known NUMS point is recognizable on sight, so publishing it bare in a control block announces that the key path was dead from the start. BIP-341 recommends against it: pick a fresh integer r uniformly at random from 0 to n minus 1 and use H + rG instead, which is indistinguishable from an ordinary internal key. Keep r, and you can still prove to a co-signer that the point was NUMS by handing it over to recompute.
Where you see it
A NUMS point never appears in an address, only in the witness of a script path spend.
On chain the output is 34 bytes, OP_1 followed by a 32-byte push, no different from any other taproot output. The internal key is the 32 bytes following the control block's first byte, so it surfaces the first time somebody spends through the tree. An output that is funded and never script-spent never reveals it.
Descriptors make the choice explicit. BIP-386 requires every key expression under tr() to be x-only and puts the internal key first in tr(KEY, TREE), so a NUMS point there is how a descriptor states that no key path exists. The mirror case is tr(KEY) with no tree, where BIP-386 quotes BIP-341's advice that an output without a script path should still commit to an unspendable one.
A NUMS internal key makes recovery depend on the descriptor string rather than the seed phrases alone: the seeds reproduce the leaf keys, and nothing in them records the tree or the point above it. Sparrow's multisig flow tells you to keep the descriptor, and that instruction carries more weight here than for a plain key path wallet.
NUMS point vs null data transaction
A NUMS point closes one spending path, while a null data transaction makes an output unspendable outright. An OP_RETURN output is provably dead by design: nodes drop it from the UTXO set and any value assigned to it is burned. Coins behind a NUMS internal key are not burned: every condition in the script tree still spends normally. The word both share is unspendable, covering a whole output in one case and a single branch in the other.