Spesa key path

Un output Taproot può essere svuotato firmando per la sua chiave o rivelando uno script impegnato, e la via della chiave è quella silenziosa. Il BIP-341 fissa quel witness a esattamente un elemento, una firma Schnorr da 64 byte con il sighash predefinito, il che rende l'intero input 230 unità di peso, ovvero 57,5 vbyte. Per chi detiene bitcoin, una cassaforte condivisa e un pagamento individuale appaiono allora identici on-chain.

Come funziona

Un key path spend firma per la chiave dell'output, che non è la chiave scelta da nessuno: il BIP-341 la costruisce come Q = P + int(t)G, dove P è la chiave pubblica interna e t è un hash etichettato di P insieme alla radice di Merkle dell'albero degli script.

Firmare significa quindi applicare lo stesso spostamento al lato privato. La routine di riferimento nega prima la chiave segreta quando il punto interno ha una coordinata y dispari, perché i tweak di Taproot si applicano a chiavi x-only da 32 byte, poi somma t modulo l'ordine della curva. Il risultato firma secondo il BIP-340 e finisce da solo sullo stack del witness.

La validazione è un test di conteggio prima di essere un test crittografico. Un nodo legge i 32 byte del programma del witness, fallisce subito se lo stack del witness è vuoto e rimuove l'ultimo elemento come annex quando gli elementi sono due o più e quell'elemento inizia con 0x50. Se resta esattamente un elemento, si tratta di un key path spend, e quell'elemento deve risultare una firma del BIP-340 valida rispetto alla chiave dell'output. Nulla in questa procedura dice al nodo se un albero degli script sia mai stato impegnato.

La firma è di 64 byte quando è implicito SIGHASH_DEFAULT, valore 0x00, che copre l'intera transazione. Arriva a 65 byte quando si aggiunge un byte di sighash diverso, e una firma da 65 byte che porti 0x00 in quella posizione finale viene rifiutata di proposito: permetterlo consentirebbe a un miner o a qualsiasi nodo che la ritrasmette di portare una firma da 64 byte a 65, cambiando il wtxid e il tasso di commissione che il mittente intendeva.

Ciò che la firma copre è al massimo 206 byte di messaggio. Si impegna sulla versione e sul locktime della transazione, sugli hash di outpoint, importo, scriptPubKey precedente e numero di sequenza di ogni input, e sugli output.

L'aritmetica delle dimensioni ne deriva. Secondo il BIP-141, il peso della transazione è la dimensione base per tre più la dimensione totale, e la dimensione virtuale è quel peso diviso quattro, arrotondato per eccesso per una transazione intera. Un input Taproot contribuisce con 41 byte base (un outpoint da 36 byte, un byte di lunghezza per uno scriptSig vuoto, un numero di sequenza da quattro byte) e 66 byte di witness (un conteggio dello stack, un prefisso di lunghezza, la firma), dando 41 per 3 più 107, ovvero 230 unità di peso, e quindi 57,5 vbyte.

Una raccomandazione del BIP-341 coglie di sorpresa gli autori di wallet. Un output senza alcuno script dovrebbe comunque impegnare un tweak, calcolato come hash etichettato della sola chiave interna, invece di pubblicare la chiave interna intatta. La specifica spiega perché: quando due parti sommano le loro chiavi in una chiave di output condivisa, una delle due può inserirvi in silenzio un tweak che nasconde un percorso di script spendibile solo da lei, e l'altra non ha modo di accorgersene.

Perché questo conta quando compri bitcoin

Il messaggio di firma di Taproot è la ragione per cui un wallet hardware può calcolare la tua commissione senza fidarsi del computer a cui è collegato.

Con il BIP-143, le regole della versione 0 di SegWit, il messaggio copriva l'importo speso dall'input firmato e nulla più. Un dispositivo che firmava un input di una transazione a tre input doveva ricevere gli altri due importi e non poteva verificarli, ed è la breccia che un host compromesso sfrutta per farti firmare commissioni molto più alte di quelle mostrate sullo schermo. Il BIP-341 si impegna sugli importi di ogni input speso dalla transazione e su tutti i loro scriptPubKey precedenti, così un firmatario può sommarli da sé. Quell'aggiornamento copre anche gli script path spend, ma è sul key path che lo incontrerà la maggior parte dei proprietari dei dispositivi delle nostre 41 recensioni di wallet.

Il tuo wallet deve poter derivare le chiavi prima che tutto questo si applichi, e in quelle recensioni il quadro è disomogeneo. KeepKey ha aggiunto il supporto agli output Taproot nel firmware 7.10.0 a febbraio 2025. L'annuncio di MetaMask elenca ancora Taproot come in arrivo, quindi non può darti un indirizzo bc1p su cui ricevere, qualunque cosa faccia il resto del suo supporto a bitcoin.

Le commissioni pendono verso il key path per un piccolo margine per input, che si accumula nella direzione in cui compra la maggior parte dei lettori. L'input P2WPKH firmato nel vettore di test dello stesso BIP-143 porta una firma da 71 byte e una chiave da 33 byte, 107 byte di witness una volta contati il conteggio dello stack e i prefissi di lunghezza, che danno 271 unità di peso, ovvero 67,75 vbyte. Un input per key path risparmia 10,25 vbyte rispetto a quello, quindi chi ha accumulato 30 piccoli acquisti separati e in seguito li consolida riduce di circa 307 vbyte quella singola transazione.

Sii chiaro su cosa compra davvero la privacy. Nascondere la tua politica di spesa non è nascondere la tua storia: se i bitcoin sono arrivati da uno dei 63 exchange recensiti da questo sito, quella piattaforma detiene già i tuoi documenti d'identità e l'indirizzo di prelievo, e nessun formato di firma tocca questo. Quello che resta nascosto è se il bitcoin era protetto da una chiave o da un quorum con un ramo di recupero di un avvocato, e quel secondo fatto è ciò che rende un indirizzo degno di essere preso di mira.

Passo per passo in taproot_sign_key

taproot_sign_key è la routine di riferimento che il BIP-341 pubblica per produrre esattamente questo witness, e nell'insieme sono nove righe di Python.

Prende un albero degli script, la chiave segreta interna, un tipo di sighash e la casualità ausiliaria che chiede il BIP-340. Quando l'albero degli script è vuoto imposta l'input del tweak a una stringa di byte vuota; altrimenti quell'input è la radice di Merkle restituita dalla funzione ausiliaria dell'albero. Applica il tweak alla chiave segreta interna con quel valore, firma il sighash, aggiunge il byte del tipo di hash solo quando il tipo non è zero e restituisce una lista con un solo elemento. Quell'elemento è l'intero witness.

Due dettagli meritano attenzione. Il ramo vuoto non è il caso senza tweak che sembra, perché passare una stringa di byte vuota lascia il tweak come hash etichettato della sola chiave interna, che è esattamente l'impegno non spendibile che la specifica raccomanda per un output senza script. E l'argomento di casualità appartiene al BIP-340 e non a Taproot: una volta applicato il tweak alla chiave, il risultato è una firma Schnorr ordinaria, ed è per questo che i key path spend non richiedono alcun trattamento speciale per essere verificati in blocco.

Key path spend vs P2TR

P2TR è il tipo di output, e un key path spend è uno dei due modi per svuotarne uno. Un bitcoin resta un bitcoin P2TR qualunque sia la via che in seguito lo sposta. La distinzione conta quando qualcuno ti dice che gli indirizzi Taproot sono privati: ricevere su uno pubblica una chiave da 32 byte e nient'altro in ogni caso, mentre la privacy di cui si parla arriva al momento della spesa, e solo se la via presa è quella della chiave.

Key path spend vs MuSig2

MuSig2 è un modo per produrre la firma che serve a un key path spend, non un suo requisito. Un singolo proprietario che firma con una sola chiave fa un key path spend ogni volta che paga, senza alcun protocollo di aggregazione in vista. I due si confondono perché l'aggregazione è il caso interessante: MuSig2 permette a più parti di arrivare a una chiave e a una firma, così il loro regolamento prende la stessa via e gli stessi 57,5 vbyte di chi paga un pranzo. Vale anche al contrario, dato che una chiave aggregata può stare dentro una foglia di script, dove spenderla è uno script path spend che usa MuSig2.