Glossaire / Adresses et clés
Point NUMS
- Qu'est-ce qu'un point NUMS ?
- Un point NUMS est une clé publique dont personne ne détient la clé privée, utilisée comme clé interne taproot lorsque la voie de dépense coopérative doit être impossible.
Spécifié dans BIP-341.
Nothing Up My Sleeve (rien dans les manches) désigne la propriété : le point provient d'une recette publique et reproductible, de sorte que personne ne peut revendiquer une clé secrète pour lui. Le BIP-341 publie un tel point, la coordonnée x 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0, obtenue en hachant l'encodage non compressé standard du point de base G de secp256k1. Pour un portefeuille, c'est ainsi qu'une sortie taproot devient script-only : dépensable par son arbre de conditions et par rien d'autre.
Comment cela fonctionne
Un point NUMS naît d'un hachage, pas d'une clé.
Une clé publique ordinaire est le générateur G multiplié par un nombre secret, et quiconque a choisi ce nombre peut signer. Un point NUMS se construit à l'envers : prenez une chaîne publique fixe, hachez-la, et lisez le condensat de 32 octets comme une coordonnée x. L'exemple du BIP-341 hache l'encodage non compressé standard de G lui-même, ce qui ne laisse à l'auteur aucune liberté pour truquer l'entrée. Élever cette valeur en un point de la courbe donne une clé publique valide à tous égards sauf un : signer pour elle supposerait de résoudre un logarithme discret, et le BIP-341 cite 1 sur 2 à la puissance 128 comme borne de sécurité du dispositif.
Taproot fournit le reste. Une clé de sortie taproot est la clé interne P décalée le long de la courbe par un ajustement qui engage la racine de merkle de l'arbre de scripts : le BIP-341 pose t = hash_TapTweak(p || merkle_root), puis Q = P + int(t)G. Signer pour Q sur la voie de clé exige la clé privée derrière P, donc lorsque P est un point NUMS cette voie est fermée et la voie de script est le seul accès. Une telle dépense révèle une feuille plus un bloc de contrôle de 33 + 32m octets, où m est le nombre de hachages frères, plafonné par le BIP-341 à 128.
Une fuite vaut la peine d'être connue. Un point NUMS bien connu est reconnaissable au premier coup d'œil, donc le publier tel quel dans un bloc de contrôle annonce que la voie de clé était morte dès le départ. Le BIP-341 le déconseille : choisissez un nouvel entier r tiré uniformément au hasard entre 0 et n moins 1 et utilisez H + rG à la place, ce qui est indiscernable d'une clé interne ordinaire. Conservez r, et vous pouvez encore prouver à un cosignataire que le point était NUMS en le lui remettant pour qu'il recalcule.
Où le voit-on
Un point NUMS n'apparaît jamais dans une adresse, seulement dans le witness d'une dépense par voie de script.
On-chain la sortie fait 34 octets, OP_1 suivi d'un push de 32 octets, sans différence avec n'importe quelle autre sortie taproot. La clé interne correspond aux 32 octets qui suivent le premier octet du bloc de contrôle, donc elle surgit la première fois que quelqu'un dépense via l'arbre. Une sortie alimentée et jamais dépensée par script ne la révèle jamais.
Les descripteurs rendent le choix explicite. Le BIP-386 exige que toute expression de clé sous tr() soit x-only et place la clé interne en premier dans tr(KEY, TREE), donc un point NUMS à cet endroit est la façon dont un descripteur énonce qu'aucune voie de clé n'existe. Le cas symétrique est tr(KEY) sans arbre, où le BIP-386 cite le conseil du BIP-341 selon lequel une sortie sans voie de script devrait tout de même engager une voie non dépensable.
Une clé interne NUMS fait dépendre la récupération de la chaîne du descripteur plutôt que des seules phrases de récupération : les phrases reproduisent les clés des feuilles, et rien en elles n'enregistre l'arbre ni le point au-dessus. Le flux multisig de Sparrow vous invite à conserver le descripteur, et cette instruction pèse ici plus lourd que pour un portefeuille à simple voie de clé.
Point NUMS vs transaction de données nulles
Un point NUMS ferme une voie de dépense, tandis qu'une transaction de données nulles rend une sortie non dépensable d'emblée. Une sortie OP_RETURN est morte de façon démontrable par construction : les nœuds la retirent de l'ensemble UTXO et toute valeur qui lui est affectée est brûlée. Les bitcoins derrière une clé interne NUMS ne sont pas brûlés : chaque condition de l'arbre de scripts se dépense normalement. Le mot que les deux partagent est non dépensable, couvrant une sortie entière dans un cas et une seule branche dans l'autre.