Punto NUMS

Nothing Up My Sleeve è la proprietà: il punto deriva da una ricetta pubblica e ripetibile, quindi nessuno può rivendicarne una chiave segreta. BIP-341 pubblica uno di questi punti, la coordinata x 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0, ottenuta calcolando l'hash della codifica standard non compressa del punto base G di secp256k1. Per un wallet, è così che un output taproot diventa solo script: spendibile attraverso il suo albero di condizioni e nient'altro.

Come funziona

Un punto NUMS nasce come hash, non come chiave.

Una chiave pubblica ordinaria è il generatore G moltiplicato per un numero segreto, e chi ha scelto quel numero può firmare. Un punto NUMS si costruisce al contrario: si prende una stringa pubblica fissa, se ne calcola l'hash e si legge il digest di 32 byte come coordinata x. L'esempio in BIP-341 calcola l'hash della codifica standard non compressa di G stesso, il che non lascia all'autore alcuna libertà di manomettere l'input. Sollevare quel valore a un punto della curva dà una chiave pubblica valida sotto ogni aspetto tranne uno: firmare per essa significherebbe risolvere un logaritmo discreto, e BIP-341 indica 1 su 2 alla 128 come limite di sicurezza del progetto.

Taproot fornisce il resto. Una chiave di output taproot è la chiave interna P spostata lungo la curva da un tweak che impegna la radice di merkle dell'albero degli script: BIP-341 pone t = hash_TapTweak(p || merkle_root), poi Q = P + int(t)G. Firmare per Q sul percorso della chiave richiede la chiave privata dietro P, quindi quando P è un punto NUMS quel percorso è chiuso e il percorso dello script è l'unica via d'ingresso. Una spesa così rivela una foglia più un blocco di controllo di 33 + 32m byte, dove m è il numero di hash fratelli, con un limite fissato da BIP-341 a 128.

C'è una fuga di informazioni che vale la pena conoscere. Un punto NUMS ben noto è riconoscibile a vista, quindi pubblicarlo così com'è in un blocco di controllo annuncia che il percorso della chiave era morto fin dall'inizio. BIP-341 lo sconsiglia: scegli un intero r nuovo uniformemente a caso da 0 a n meno 1 e usa invece H + rG, che è indistinguibile da una chiave interna ordinaria. Conserva r e potrai comunque dimostrare a un cofirmatario che il punto era NUMS consegnandoglielo per ricalcolarlo.

Dove lo vedi

Un punto NUMS non appare mai in un indirizzo, solo nel witness di una spesa sul percorso dello script.

On-chain l'output è di 34 byte, OP_1 seguito da un push di 32 byte, identico a qualsiasi altro output taproot. La chiave interna sono i 32 byte che seguono il primo byte del blocco di controllo, quindi emerge la prima volta che qualcuno spende attraverso l'albero. Un output che riceve fondi e non viene mai speso tramite lo script non la rivela mai.

I descrittori rendono esplicita la scelta. BIP-386 richiede che ogni espressione di chiave sotto tr() sia x-only e mette la chiave interna per prima in tr(KEY, TREE), quindi un punto NUMS lì è il modo in cui un descrittore dichiara che non esiste alcun percorso della chiave. Il caso speculare è tr(KEY) senza albero, dove BIP-386 cita il consiglio di BIP-341 secondo cui un output senza percorso dello script dovrebbe comunque impegnare un percorso non spendibile.

Una chiave interna NUMS fa dipendere il ripristino dalla stringa del descrittore anziché dalle sole frasi di recupero: le frasi riproducono le chiavi delle foglie, e nulla in esse registra l'albero né il punto sopra di esso. Il flusso multisig di Sparrow ti dice di conservare il descrittore, e quell'istruzione qui pesa più che per un wallet ordinario con percorso della chiave.

Punto NUMS vs transazione a dati nulli

Un punto NUMS chiude un percorso di spesa, mentre una transazione a dati nulli rende un output non spendibile del tutto. Un output OP_RETURN è dimostrabilmente morto per progetto: i nodi lo rimuovono dall'insieme degli UTXO e qualsiasi valore assegnato ad esso viene bruciato. I bitcoin dietro una chiave interna NUMS non vengono bruciati: ogni condizione dell'albero degli script si spende comunque normalmente. La parola che entrambi condividono è non spendibile, che in un caso copre un intero output e nell'altro un solo ramo.