blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il blocco 481.824, con timestamp 01:57:37 UTC del 24 agosto 2017, contiene 1.866 transazioni in 989.323 byte e pesa 3.954.880 unità: rispetta nello stesso momento il vecchio tetto di 1 MB e il nuovo da 4 milioni di unità, con appena 800 byte circa di dati witness. Il blocco 709.632, con timestamp 05:15:27 UTC del 14 novembre 2021, è lungo 1.410.904 byte, ben oltre 1 MB, eppure pesa 3.881.749 unità, perché circa 587.000 dei suoi byte sono witness. Il primo ha aperto SegWit, il secondo Taproot. La distanza tra le loro dimensioni è la strada più breve per capire SegWit e Taproot: che cosa ha cambiato ciascun aggiornamento e perché il secondo aveva bisogno del primo.
Sono due soft fork del formato delle transazioni di Bitcoin ed entrambi sono entrati dalla stessa porta. La versione 0 del witness, cioè SegWit, ha tolto le firme dall’ID della transazione e ha introdotto il peso. La versione 1, Taproot, ha portato le firme Schnorr, un albero di script di spesa nascosti e una spesa che appare identica sia che dietro ci sia una chiave sola sia che ci sia un comitato. Nei 144 blocchi minati fino alle 09:30 UTC del 9 novembre 2026, l’89,9% delle transazioni conteneva dati witness, secondo il conteggio dei blocchi grezzi fatto da Coindaro e descritto più avanti.
Questa lezione segue quella precedente del percorso, come funzionano le transazioni e gli script di Bitcoin, che smonta una transazione byte per byte, esegue uno script P2PKH un opcode alla volta ed elenca i tipi di output con i prefissi degli indirizzi. Qui quei meccanismi si danno per noti. Quello che segue è ciò che è cambiato nel 2017 e nel 2021, e quanto è costato.
SegWit vs Taproot: due aggiornamenti dalla stessa porta
Un soft fork restringe le regole in modo che i blocchi prodotti dai miner aggiornati restino validi anche per i nodi che non si sono mai aggiornati. La nostra guida a soft fork e hard fork spiega la differenza, come i miner segnalano il consenso con un bit di versione e la vicenda di SegWit nel 2017, dal voto fermo sotto il 95% alla scadenza del 1° agosto del BIP 148, fino alla finestra più corta della Speedy Trial di Taproot nel 2021. Di quel meccanismo qui conta un solo dettaglio: il trucco che ha reso possibili entrambi gli aggiornamenti.
SegWit ha definito un nuovo tipo di output, il witness program: un piccolo numero da 0 a 16 (la versione) seguito da 2 a 40 byte di dati. Per un nodo con software precedente al 2017, un output simile è uno script che mette in pila due elementi e lascia sulla pila un valore diverso da zero, quindi chiunque può spenderlo con una prova vuota. Per un nodo aggiornato, il numero di versione sceglie un insieme di regole e la prova deve stare in un posto nuovo, il witness. Il BIP 141 lo dice senza giri di parole: i nodi non aggiornati «considereranno tutti i witness program come script spendibili da chiunque» (traduzione nostra). I vecchi nodi non vedono mai una moneta rubata, perché i miner che applicano le nuove regole non mettono mai un furto del genere in un blocco.
La versione 0 è stata usata da SegWit nel 2017. La versione 1 è rimasta indefinita, e quindi spendibile da chiunque, finché Taproot non le ha dato regole nel 2021. Il BIP 341 ripete l’argomento quasi parola per parola: «I nodi non aggiornati, però, considereranno tutti i witness program SegWit di versione 1 come script spendibili da chiunque» (traduzione nostra). Le versioni da 2 a 16 sono ancora libere oggi, ed è così che arriverebbe un eventuale cambiamento futuro dello stesso tipo.
Dalla proposta alla regola attiva, blocco per blocco
Un pezzo del percorso del 2017 manca nella maggior parte dei resoconti brevi. Il BIP 91, una regola gestita dai miner con una soglia di 269 blocchi su 336 (l’80%), era stato scritto per attivare il dispiegamento esistente «con una maggioranza di hashpower inferiore al 95%» (traduzione nostra): una volta attivo, dal blocco 477.120, rifiutava ogni blocco che non segnalasse SegWit. Le altezze qui sotto sono state verificate su mempool.space; gli orari sono i timestamp dei blocchi, che possono scostarsi dall’ora reale di un’ora o più.
| Data (timestamp del blocco, UTC) | Blocco | Evento |
|---|---|---|
| 21 dic 2015 | Al BIP 141 (Segregated Witness) viene assegnato il numero | |
| 27 ott 2016 | Esce Bitcoin Core 0.13.1 con il codice di dispiegamento di SegWit | |
| 15 nov 2016 | Si apre la segnalazione BIP 9 per «segwit» (bit 1) | |
| 21 lug 2017 | 476.784 | BIP 91 si blocca (locked in) dal periodo di 336 blocchi che parte qui |
| 23 lug 2017 | 477.120 | BIP 91 attivo: i blocchi che non segnalano SegWit vengono rifiutati |
| 9 ago 2017, 12:36 | 479.808 | Primo blocco del periodo in cui SegWit risulta bloccato (locked in) |
| 24 ago 2017, 01:57 | 481.824 | SegWit attivo, esattamente 2.016 blocchi dopo |
| 24 apr 2021 | Si apre la finestra di segnalazione di Taproot (bit 2, 1.815 blocchi su 2.016) | |
| 13 giu 2021, 20:06 | 687.455 | Ultimo blocco del periodo in cui è stata superata la soglia del 90% |
| 13 giu 2021, 20:07 | 687.456 | Taproot bloccato (locked in), attivazione fissata al blocco 709.632 |
| 14 nov 2021, 05:15 | 709.632 | Taproot attivo (altezza minima di attivazione indicata nel BIP 341) |
Il New York Agreement e il confronto tra i metodi di attivazione appartengono a una lezione successiva di questo percorso, dedicata alla governance di Bitcoin. Il resto di questa lezione riguarda ciò che le regole fanno.
Il problema che SegWit ha risolto: un ID di transazione modificabile da altri
Un txid è il doppio hash SHA-256 dei byte della transazione. Prima del 2017 quei byte comprendevano le firme, e una firma poteva essere riscritta senza essere spezzata. ECDSA ha una simmetria incorporata: se (r, s) è una firma valida, lo è anche (r, n – s), dove n è l’ordine della curva. Per questo il BIP 340 definisce le firme ECDSA «intrinsecamente malleabili» (traduzione nostra). Chiunque inoltrasse una transazione non confermata poteva invertire s, o aggiungere nello scriptSig un push in più innocuo, e trasmettere una versione con un txid diverso che spendeva le stesse monete verso gli stessi destinatari.
Per un pagamento semplice era una seccatura: i soldi arrivavano, sotto un ID che chi aveva inviato non si aspettava. Per qualsiasi cosa costruita sopra una transazione non confermata era fatale. Una seconda transazione che spende un output della prima la indica per txid. Se la prima viene minata con un altro ID, la seconda punta nel vuoto e non può mai confermarsi. I contratti che richiedono una transazione di rimborso firmata prima che venga trasmessa quella di finanziamento, la base dei canali di pagamento, non si potevano costruire in sicurezza su quel terreno.
Gli sviluppatori provarono a chiudere le falle una alla volta. Il BIP 66 rese obbligatoria nel 2015, come regola di consenso, la codifica DER rigorosa, il BIP 147 corresse l’elemento fittizio di OP_CHECKMULTISIG, e il BIP 62, un elenco più ampio di regole contro la malleabilità, finì con lo stato Closed. Ogni correzione copriva un solo vettore; nessuna copriva chi firma di nuovo di proposito. SegWit imboccò un’altra strada. Il suo testo ne riassume il risultato in una riga:
«Segregated witness risolve alla radice il problema della malleabilità delle transazioni, il che permette di costruire catene di dipendenza tra transazioni non confermate senza bisogno di fiducia.» (traduzione nostra) BIP 141
Il metodo consiste nel lasciare le firme fuori dall’hash che dà il nome alla transazione. In una spesa SegWit lo scriptSig è vuoto, la prova sta nel witness e il txid si calcola da una serializzazione senza witness. Cambiare una firma non cambia più l’ID a cui le altre transazioni puntano. Le note di rilascio di Bitcoin Core 0.13.1 del 27 ottobre 2016 descrivono questo risultato come la soluzione di «tutti i casi noti di malleabilità indesiderata delle transazioni» (traduzione nostra). Gli input legacy sono rimasti malleabili come prima, ed è per questo che una transazione che li mescola con input SegWit non può contare sul mantenimento del proprio ID.
Che cosa ha cambiato SegWit dentro una transazione
Un witness per ogni input e un secondo ID per l’insieme
La lezione 1 ha mostrato il byte marcatore 0x00 e il byte flag 0x01 che aprono una transazione SegWit, e le pile witness collocate dopo gli output. Il BIP 144 definisce quella serializzazione e la regola su cui contano i vecchi nodi: a loro non viene mai inviata questa forma, ma solo la transazione privata di marcatore, flag e witness, che è esattamente la forma il cui hash dà il txid. La forma completa ha un suo hash, il wtxid.
Il witness deve comunque essere legato al blocco, altrimenti un miner potrebbe sostituirlo. Il BIP 141 lo fa attraverso la coinbase: i wtxid di tutte le transazioni vanno in un secondo albero di Merkle, e la sua radice è scritta in un output della transazione coinbase il cui script comincia con i byte 0x6a24aa21a9ed, un OP_RETURN seguito dall’intestazione aa21a9ed. Un block explorer mostra questo output in ogni blocco che contiene transazioni SegWit, cioè dal 2017 quasi tutti. I vecchi nodi lo leggono come un normale output di dati.
Il peso: il limite di 4 milioni di unità al posto di 1 MB
Togliere le firme dalla vecchia serializzazione le ha tolte anche dal vecchio conteggio delle dimensioni, e il BIP 141 ha sostituito il limite di 1 MB con un limite sul peso. Il peso di una transazione è la sua dimensione di base (senza witness) moltiplicata per tre, più la sua dimensione totale; un blocco può pesare al massimo 4.000.000 di unità. I byte non witness contano quattro unità ciascuno, quelli witness una. La dimensione virtuale è il peso diviso quattro, arrotondato per eccesso, ed è a questa che si applicano i tassi di commissione in sat/vB. La nostra guida alla mempool e alle commissioni di transazione mostra come i wallet usano i vbyte per fissare una commissione; la lezione 1 sviluppa la formula su una transazione reale da 565 unità.
I due blocchi dell’apertura mostrano la regola al lavoro. Nel blocco 481.824 dimensione di base e dimensione totale sono quasi uguali, quindi è un classico blocco da 1 MB che soddisfa anche la nuova regola. Nel blocco 709.632 circa 587.000 byte sono witness e circa 824.000 sono dati di base: tre volte la base più il totale dà 3.881.749. Un blocco può avvicinarsi a 4 MB solo se è quasi interamente witness, cosa che i pagamenti ordinari non sono. Nelle note di rilascio della 0.13.1, Bitcoin Core stimava che la rete potesse sostenere «circa il 70% di transazioni in più» se tutti i wallet fossero passati a SegWit (traduzione nostra), una proiezione fatta sul contenuto dei blocchi del 2016, non un risultato misurato.
Il BIP 141 elenca questo sconto tra i vantaggi del progetto e lo descrive come un aumento effettivo della dimensione del blocco «in una certa misura» (traduzione nostra). Se fosse una risposta adeguata alla richiesta di blocchi più grandi è la vecchia disputa; la regola in sé non è cambiata dal 2017.
Un nuovo hash di firma con l’importo dentro
Il BIP 143 ha cambiato ciò a cui si impegna una firma SegWit, e così facendo ha risolto due vecchi problemi. Negli script legacy ogni verifica di firma ricalcola l’hash di quasi tutta la transazione, per cui il lavoro di hashing cresce con il quadrato del numero di operazioni di firma. Il BIP 143 riporta il caso peggiore: «una transazione da 1 MB con 5569 sigop può richiedere 25 secondi per essere verificata» (traduzione nostra), contro circa 2 secondi per un normale blocco da 1 MB su un computer del 2015. Il nuovo algoritmo calcola una sola volta l’hash delle parti condivise e le riutilizza, quindi il costo cresce in modo lineare.
La seconda correzione riguarda gli hardware wallet. Una firma legacy non si impegna sull’importo della moneta spesa, quindi un dispositivo offline doveva ricevere l’intera transazione precedente per sapere che cosa stava firmando, e quale fosse la commissione. Con il BIP 143 ogni firma si impegna sull’importo del proprio input. Se qualcuno mente al dispositivo su quell’importo, la firma che produce è semplicemente non valida.
I programmi di versione 0: P2WPKH, P2WSH e la forma annidata
La versione 0 ha due programmi, distinti dalla lunghezza. Un programma di 20 byte è l’hash di una chiave pubblica (P2WPKH): il witness deve contenere una firma e quella chiave. Un programma di 32 byte è l’hash SHA-256 di uno script (P2WSH): il witness contiene gli input e lo script stesso, che può arrivare a 10.000 byte. Il BIP 141 spiega l’hash più lungo, 32 byte contro i 20 di P2SH, come protezione dagli attacchi di collisione, perché 2 alla 80 operazioni non erano più fuori portata.
Nel 2017 la maggior parte dei wallet e degli exchange non poteva ancora pagare verso i nuovi output, e il BIP 141 definì perciò anche una forma annidata: il witness program viene messo dentro un normale output P2SH, un indirizzo che comincia con 3. Chi invia vede un indirizzo familiare; chi riceve ottiene gran parte dello sconto witness quando spende. Questo SegWit «annidato» o «wrapped» è uno dei motivi per cui la quota di P2SH nella tabella di adozione qui sotto è rimasta alta per anni dopo il 2017.
I nuovi output nativi di versione 0 hanno ricevuto una nuova codifica degli indirizzi, bech32, definita nel BIP 173, con indirizzi che cominciano per bc1q. Gli output Taproot usano bech32m (BIP 350) e cominciano per bc1p. Lunghezze, checksum e il motivo per cui serviva bech32m sono nella nostra guida agli indirizzi crypto.
Perché la correzione della malleabilità ha contato più dello sconto
Il risparmio sulle commissioni era l’argomento di vendita per gli utenti, ma ciò che gli sviluppatori aspettavano era la correzione della malleabilità. Un canale Lightning si apre con una transazione di finanziamento che blocca le monete in un output multisig 2-di-2, e ciascuna parte tiene transazioni firmate che spendono quell’output prima ancora che sia confermato. Quelle spese pre-firmate fanno riferimento alla transazione di finanziamento tramite txid. Con un txid malleabile, la controparte o un nodo qualsiasi che inoltrava avrebbe potuto renderle inutili e lasciare le monete bloccate.
Una volta attivo SegWit, l’ID di una transazione i cui input sono tutti SegWit è fissato nel momento in cui viene firmata. La nostra guida a layer 1 e layer 2 offre il quadro generale di Lightning; la prossima lezione di questo percorso lo tratta a fondo, con canali, instradamento e limiti. Taproot è tornato su Lightning più tardi: Bitcoin Optech ha registrato che LND v0.17.0-beta ha distribuito nel 2023 canali Taproot e MuSig2 sperimentali, e che Core Lightning ha reso Pay-to-Taproot il valore predefinito per le spese di ancoraggio (anchor) e le chiusure unilaterali nel novembre 2024.
Taproot: tre BIP e un nuovo output
Taproot è il nome comune di tre documenti di Pieter Wuille, Jonas Nick e Anthony Towns (Tim Ruffing al posto di Towns per il BIP 340): le firme Schnorr (BIP 340), l’output Taproot e le sue regole di spesa (BIP 341) e le regole degli script al suo interno, tapscript (BIP 342). Il loro output, P2TR, è un witness program di versione 1 con 32 byte di dati, e quei 32 byte sono una chiave pubblica, non un hash.
Le firme Schnorr, verificate con una sola equazione
La nostra guida alla crittografia presenta le firme Schnorr in poche righe: stessa curva secp256k1 di ECDSA, chiavi pubbliche da 32 byte, firme da 64 byte. La regola di verifica mostra perché contano. Una firma è un punto R e un numero s; è valida per la chiave P e il messaggio m quando s per il generatore G è uguale a R più hash(R, P, m) per P. Ogni termine è una somma di punti, senza inversioni né divisioni, a differenza di ECDSA.
Questa forma è lineare: le chiavi e le firme parziali di più persone possono essere sommate in una sola chiave e una sola firma. Il BIP 340 descrive anche la verifica in batch, cioè molte firme controllate insieme più in fretta che una per una, e la non malleabilità: una firma valida non può essere riscritta in un’altra firma valida, e il trucco (r, n – s) di ECDSA sparisce. La codifica fissa a 64 byte sostituisce il DER, la cui lunghezza variabile aveva causato problemi di consenso prima del BIP 66.
La chiave modificata: un albero di script ripiegato in una chiave pubblica
Una chiave di output Taproot Q si costruisce da una chiave interna P e da un insieme facoltativo di script. Gli script sono le foglie di un albero di Merkle; la sua radice, chiamiamola k, viene sottoposta a hash insieme a P in un numero t, e la chiave di output è Q = P + tG. Chi conosce P e k può verificare che Q si impegni su di essi. Chi vede solo Q vede una chiave pubblica come tante altre. Quando non ci sono script, il BIP 341 raccomanda comunque di modificare la chiave con un hash del solo P, in modo che nessun co-proprietario possa infilare un percorso di script ignoto agli altri.
Il key path: una firma e nient’altro in vista
Il primo modo di spendere è il key path, il percorso della chiave: una sola firma Schnorr da 64 byte valida per Q, oppure da 65 byte se si usa un flag sighash non predefinito. Nel witness non va nient’altro. La chiave interna, gli script e perfino il fatto che degli script esistessero restano fuori dalla catena. Una persona sola con una chiave sola produce esattamente questo. Lo produce anche un gruppo che ha combinato le proprie chiavi in una con MuSig2, il protocollo multifirma pubblicato come BIP 327, in cui ogni firmatario contribuisce con una firma parziale e il risultato è un’unica firma dall’aspetto ordinario.
Il BIP 341 ha cambiato ancora una volta l’hash di firma. Una firma Taproot si impegna sugli importi e sugli script di output di tutti gli input spesi, e non soltanto del proprio, il che per il BIP 341 «elimina la possibilità di mentire ai dispositivi di firma offline sulla commissione di una transazione» (traduzione nostra). Il BIP 143 proteggeva l’importo di un solo input; qui è coperta l’intera transazione.
Lo script path: rivelare un ramo dell’albero
Il secondo modo è lo script path, il percorso dello script, usato quando le parti non possono o non vogliono firmare tutte. Chi spende rivela una foglia, gli input che la soddisfano e un control block di 33 + 32m byte: un byte per la versione della foglia e la parità di Q, i 32 byte della chiave interna, poi m hash da 32 byte che provano che la foglia sta nell’albero, con m al massimo 128. I nodi ricalcolano la radice, verificano che P modificata con essa dia Q, poi eseguono lo script. Viene pubblicato solo il ramo usato; le altre foglie restano nascoste.
È l’idea a lungo discussa come MAST, alberi sintattici astratti di Merkle (Merkelized abstract syntax trees), arrivata come parte di Taproot. Un contratto con dieci possibili vie d’uscita metteva tutte e dieci in uno script P2SH o P2WSH e le rivelava tutte alla spesa. Con Taproot ne rivela una, con una prova la cui dimensione cresce con la profondità dell’albero e non con il numero delle foglie.
Tapscript: che cosa è cambiato dentro gli script
Gli script eseguiti con versione di foglia 0xc0 seguono il BIP 342. OP_CHECKSIG e OP_CHECKSIGVERIFY ora verificano firme Schnorr con chiavi da 32 byte. OP_CHECKMULTISIG e OP_CHECKMULTISIGVERIFY sono disabilitati, perché non si possono verificare in batch: provano le chiavi in ordine finché le firme coincidono. Una politica k-di-n si scrive invece con il nuovo OP_CHECKSIGADD (opcode 186), che controlla una chiave e somma 1 a un contatore quando la firma è valida; lo script finisce confrontando il contatore con k. L’elemento fittizio dovuto all’errore di conteggio del vecchio opcode, trattato nella lezione 1, sparisce con lui.
Sono stati eliminati due limiti. Il limite di 10.000 byte per la dimensione dello script non vale in tapscript, e nemmeno quello di 201 opcode non-push: il BIP 342 dice che la dimensione è «solo implicitamente limitata dal limite di peso del blocco» (traduzione nostra). Il motivo riguarda il costo di verifica, dato che lo script non viene più sottoposto a hash di nuovo a ogni controllo di firma. I controlli di firma hanno invece un budget proprio: 50 più la dimensione del witness dell’input, con ogni controllo di firma eseguito che costa 50. Restano il limite di 520 byte per elemento della pila e quello di 1.000 elementi sulla pila.
Il BIP 342 ha anche ribattezzato OP_SUCCESSx un elenco di opcode inutilizzati: uno script che ne contiene uno è valido senza condizioni. Sembra avventato, ma è la stessa porta di servizio delle versioni witness, un livello più in basso. Un futuro soft fork può dare un significato a uno di quegli opcode e rendere non validi alcuni di quegli script, il che restringe soltanto le regole. Le versioni di foglia e i tipi di chiave pubblica sconosciuti sono tenuti liberi per lo stesso scopo.
Un esempio svolto: un caveau di risparmio 2-di-3 con una via di recupero
Un’architettura illustrativa mostra insieme i due percorsi. Tre chiavi appartengono ad Alice, Bob e a un servizio di backup; due qualsiasi possono spendere, e dopo un anno senza movimenti una chiave di recupero separata può svuotare le monete da sola. La chiave interna è un’aggregazione MuSig2 delle chiavi di Alice e Bob, la coppia che dovrebbe firmare quasi sempre. L’albero ha tre foglie: Alice più il backup, Bob più il backup, e la chiave di recupero dietro un timelock relativo di 52.560 blocchi (circa un anno), il blocco OP_CHECKSEQUENCEVERIFY spiegato nella lezione 1.
In un giorno normale Alice e Bob firmano insieme attraverso il key path. La catena vede una firma da 64 byte, un input di circa 57,5 vbyte, e niente che le dica che esistono un caveau, un servizio di backup o un piano di recupero. Se Bob perde il telefono, Alice e il backup spendono attraverso la loro foglia: la catena vede quella sola foglia con le sue due chiavi e le sue due firme, più un control block con uno o due hash, e ancora niente sul ramo di recupero. In P2WSH la stessa politica metterebbe sulla catena tutte le chiavi e l’intera condizione di timelock a ogni spesa.
Legacy, SegWit e Taproot a confronto
Le dimensioni sono quelle del calcolatore di dimensione delle transazioni di Bitcoin Optech, che ipotizza firme ECDSA da 72 byte (il limite massimo; con la firma a R basso diventano 71) e chiavi compresse da 33 byte. L’input SegWit annidato è una somma di Coindaro con gli stessi campi: 64 byte non witness e un witness da 108 byte, quindi 64 + 27 = 91 vbyte.
| Legacy P2PKH | SegWit annidato (P2SH-P2WPKH) | SegWit nativo P2WPKH | Taproot P2TR | |
|---|---|---|---|---|
| L’indirizzo comincia per | 1 | 3 | bc1q | bc1p |
| Versione witness | nessuna | 0, dentro P2SH | 0 | 1 |
| Firma | ECDSA, DER, 71-72 byte | ECDSA | ECDSA | Schnorr, 64-65 byte |
| Dimensione dell’input (chiave singola) | 148 vB | circa 91 vB | 68 vB | 57,5 vB (key path) |
| Dimensione dell’output | 34 vB | 32 vB | 31 vB | 43 vB |
| Dati di firma nel txid | sì (malleabile) | no | no | no |
| Che cosa rivela una spesa | chiave e firma | chiave, firma, script involucro | chiave e firma | una firma (key path) o una foglia di script |
| Esempio di input multisig | P2SH 2-di-3: 297 vB | non calcolato | P2WSH 2-di-3: 104,5 vB | 57,5 vB se i firmatari aggregano le chiavi |
Un esempio con etichette rende concreto il compromesso: un input, un output di pagamento e un output di resto, tutti dello stesso tipo. Con P2PKH legacy fa 10 + 148 + 2 x 34 = 226 vB. Con P2WPKH fa 10,5 + 68 + 2 x 31 = 140,5 vB. Con P2TR fa 10,5 + 57,5 + 2 x 43 = 154 vB. A 3 sat/vB, la tariffa più veloce indicata da mempool.space alle 10:23 UTC del 9 novembre 2026, fanno 678, circa 422 e 462 satoshi.
Quindi un pagamento Taproot a chiave singola di questa forma è un po’ più grande di uno SegWit nativo: l’output porta una chiave da 32 byte invece di un hash da 20 byte, e gli output li paga chi invia. Chi riceve paga dopo per gli input, dove Taproot è più leggero di 10,5 vbyte ogni volta. Un wallet che riceve molti piccoli pagamenti e li spende più tardi risparmia in uscita; uno che invia molti pagamenti con output di resto paga un po’ di più in entrata. Per la custodia condivisa il confronto si ribalta nettamente a favore di Taproot, come mostra la riga del multisig, ma solo quando i firmatari possono usare MuSig2 o un protocollo simile.
Cosa cambia per commissioni e privacy, e cosa no
Il guadagno di SegWit sulle commissioni è venuto dallo sconto witness e da script più piccoli, ed è grande: circa il 38% di vbyte in meno per l’esempio a un input qui sopra. Il guadagno di Taproot è piccolo per le chiavi singole e grande per le politiche con più chiavi o condizioni. Nessuno dei due cambia il mercato delle commissioni: una tariffa è ancora fissata dalla concorrenza per lo spazio nei blocchi, come descritto nella guida alla mempool.
La privacy è migliorata in un modo preciso. Prima di Taproot una spesa mostrava che tipo di lucchetto apriva, chiave singola, multisig, timelock o blocco con hash, e spesso tutte le sue condizioni. Una spesa Taproot key path ha lo stesso aspetto per una persona, per un’azienda con una politica a tre chiavi e per un canale Lightning chiuso di comune accordo. Funziona solo se molte persone usano lo stesso tipo di output; un tipo raro è di per sé un’impronta.
Conta quanto questo ciò che Taproot non ha cambiato. Gli importi sono pubblici. Gli indirizzi sono pubblici, e riusarne uno collega ancora i pagamenti. Una transazione con più input suggerisce ancora un proprietario comune, l’euristica spiegata nella nostra guida ai modelli UTXO e account, perché Taproot non ha incluso l’aggregazione delle firme tra input: ogni input porta ancora la sua firma. Il BIP 341 dice che l’idea è stata rimandata perché «interagisce in modi complessi con i meccanismi di aggiornamento» (traduzione nostra). Anche una spesa script path rivela che uno script esisteva, e quale è stato usato.
Chi usa SegWit e Taproot: istantanee datate
Non esiste una serie ufficiale unica sull’adozione, e il risultato dipende da ciò che si conta: transazioni, input, output o vbyte. La tabella è il conteggio di Coindaro su blocchi grezzi letti da mempool.space il 9 novembre 2026, e ogni riga è un campione, non una media: quattro blocchi (uno ogni tre a partire dal primo indicato, attorno alle 00:00 UTC di quella data), con ogni transazione analizzata e ogni output classificato in base al suo script. «Tx con witness» conta le transazioni che portano dati witness di qualsiasi tipo, quindi dal 2021 include Taproot. Le quote degli output sono sul totale degli output creati, compresi quelli di dati. L’ultima colonna è la quota degli input che somigliano a una spesa Taproot key path, cioè un solo elemento witness da 64 o 65 byte.
| Data del campione | Blocchi | Tx con witness | Output P2PKH | Output P2SH | Output P2WPKH | Output P2TR | Output OP_RETURN | Input Taproot key path |
|---|---|---|---|---|---|---|---|---|
| 1 ago 2017 | 478.478 a 478.487 | 0,0% | 84,0% | 14,8% | 0% | n.d. | 1,1% | n.d. |
| 1 nov 2017 | 492.557 a 492.566 | 9,2% | 84,4% | 15,3% | 0% | n.d. | 0,2% | n.d. |
| 1 nov 2018 | 548.213 a 548.222 | 36,4% | 53,2% | 35,2% | 4,3% | n.d. | 7,1% | n.d. |
| 1 nov 2019 | 601.841 a 601.850 | 46,7% | 48,8% | 36,1% | 10,4% | n.d. | 3,6% | n.d. |
| 1 nov 2020 | 654.932 a 654.941 | 39,0% | 43,6% | 43,4% | 11,1% | n.d. | 0,5% | n.d. |
| 1 nov 2021 | 707.633 a 707.642 | 81,1% | 20,9% | 44,7% | 30,3% | n.d. | 0,7% | n.d. |
| 1 nov 2022 | 761.191 a 761.200 | 81,0% | 20,5% | 38,8% | 35,6% | 0,2% | 0,4% | 0,5% |
| 1 nov 2023 | 814.748 a 814.757 | 95,3% | 9,4% | 16,0% | 38,1% | 30,0% | 4,2% | 13,6% |
| 1 nov 2024 | 868.326 a 868.335 | 98,3% | 4,9% | 4,8% | 41,2% | 23,8% | 24,2% | 20,0% |
| 1 nov 2025 | 921.682 a 921.691 | 96,8% | 5,0% | 3,7% | 46,2% | 22,3% | 20,8% | 7,3% |
| 1 nov 2026 | 974.043 a 974.052 | 98,9% | 1,9% | 1,7% | 54,3% | 3,7% | 37,4% | 4,7% |
Quattro blocchi sono un campione, non una linea di tendenza, e le colonne di Taproot lo dimostrano: il 30,0% degli output nel novembre 2023, il 3,7% tre anni dopo, con oscillazioni in mezzo che seguono le ondate di inscription e di output di dati più di qualsiasi scelta costante dei wallet. Ciò che la serie mostra è la forma. Gli output legacy P2PKH sono passati da oltre l’80% all’1,9% di tutti gli output nel campione del novembre 2026. SegWit è passato da zero a quasi tutte le transazioni dei blocchi campionati in circa sei anni, con una salita lenta fino al 2020 e un balzo entro il novembre 2021. Le chiavi native di versione 0 sono oggi il lucchetto dominante, e Taproot è un tipo di minoranza la cui quota dipende da ciò che accade d’altro nei blocchi.
Un campione più ampio dà un quadro più stabile. Sui 144 blocchi consecutivi da 975.014 a 975.157, con timestamp tra le 02:15 UTC dell’8 novembre e le 09:30 UTC del 9 novembre 2026, Coindaro ha contato 537.583 transazioni, delle quali l’89,9% portava dati witness. Lasciando da parte gli output di dati, i 1.041.956 output spendibili creati in quei blocchi erano per il 69,6% P2WPKH, per il 10,5% P2TR, per il 6,8% P2PKH, per il 5,9% P2SH e per il 3,4% P2WSH. Su 1,2 milioni di input, il 9,5% somigliava a spese Taproot key path e il 13,2% stava in transazioni senza alcun witness. Un blocco di quella finestra, il 975.157, conteneva circa 7.959 transazioni che quasi tutte accoppiavano un output SegWit nativo a un output di dati, abbastanza da solo per spostare le quote di output della giornata.
Come wallet e nodi si sono messi al passo
Le regole attive in un blocco non significano che i wallet le usino. Bitcoin Core ha distribuito la validazione di SegWit nella 0.13.1 il 27 ottobre 2016, dieci mesi prima dell’attivazione, ma il suo wallet ha reso SegWit nativo il valore predefinito solo con la 0.20.0, pubblicata il 3 giugno 2020, le cui note dicono che il wallet «ora per impostazione predefinita usa indirizzi bech32 con le RPC e crea output di resto segwit nativi» (traduzione nostra). La lenta salita della colonna witness tra il 2018 e il 2020 è coerente con quel passo, con gli indirizzi annidati come ponte. Taproot ha ripetuto il ritardo: pagare un indirizzo bc1p richiede software che conosca bech32m, che la guida agli indirizzi data per i primi wallet al 2021, e gli strumenti multiparte sono arrivati ancora più tardi, perché i firmatari MuSig2 devono scambiarsi i nonce in più round prima che esista una firma.
Come Taproot è finito a conservare immagini: il legame con Ordinals
I progettisti di Taproot scrivevano di costi delle firme e di privacy, non di archiviare file. Eppure le ondate di inscription che muovono la colonna Taproot qui sopra si appoggiano proprio su due delle sue caratteristiche. La documentazione di Ordinals ne indica il meccanismo: «Il contenuto delle inscription è interamente on-chain, memorizzato negli script di spesa script-path di taproot» (traduzione nostra). I dati stanno dentro una busta, OP_FALSE OP_IF seguito dal contenuto e da OP_ENDIF, un ramo che non viene mai eseguito, così lo script attorno funziona normalmente.
Due regole di tapscript lo rendono praticabile. Eliminato il limite di 10.000 byte per lo script, uno script di foglia può essere grande quanto consente il peso del blocco, e poiché lo script viene rivelato nel witness ogni suo byte è contato a una unità di peso invece che a quattro. Il limite di 520 byte per elemento della pila vale ancora, quindi il contenuto viene tagliato in push di al massimo 520 byte. Poiché uno script path si può usare solo spendendo un output Taproot già esistente, un’inscription richiede due transazioni: un commit che crea l’output e un reveal che lo spende e mette il contenuto sulla catena.
Se questo sia un uso legittimo dello spazio nei blocchi o spam è una disputa che questa lezione non risolve. Ha portato al tentativo del 2026 di limitare questi dati con un soft fork, il BIP-110, raccontato nella guida ai fork, ed è uno dei dibattiti della lezione sulla governance, più avanti in questo percorso. Ordinals, token BRC-20 e Runes avranno una lezione propria, dopo quella sull’esecuzione di un nodo.
Le chiavi esposte di Taproot e il dibattito quantistico
Un output P2PKH o P2WPKH conserva un hash della chiave pubblica; la chiave compare solo quando la moneta viene spesa. Un output Taproot conserva la chiave, modificata ma utilizzabile, nell’output fin dal giorno in cui la moneta arriva. Se mai esistesse una macchina in grado di risolvere il logaritmo discreto su curva ellittica, ogni output Taproot non speso sarebbe esposto finché resta sulla catena.
Il BIP 341 ne discute in una nota e ridimensiona la questione. Sostiene che nascondere una chiave dietro un hash offra una protezione «molto debole nel migliore dei casi» (traduzione nostra), dato che le chiavi vengono rivelate nella mempool a ogni spesa e che una grossa parte delle monete già sta dietro chiavi esposte, e che una vera resistenza richiede una crittografia diversa. Gli autori del BIP 360 traggono un’altra conclusione. La loro proposta, numerata il 18 dicembre 2024 e ancora in stato Draft (versione 0.12.1 al 9 novembre 2026), aggiunge un nuovo tipo di output, Pay-to-Merkle-Root, che mantiene gli alberi di script di Taproot e toglie il key path. Ne ammette il limite con parole sue: «Gli output Bitcoin sono in generale vulnerabili ad attacchi a breve esposizione, dato che la maggior parte delle transazioni Bitcoin richiede di rivelare la chiave pubblica associata al momento della spesa» (traduzione nostra).
Le stime su quando una simile macchina potrebbe esistere variano molto e nessuna è assodata. Coindaro ne ha raccontata una recente, lo studio di Alice & Bob sui qubit cat e la curva di Bitcoin, le cui cifre poggiano su ipotesi che nessuna macchina esistente soddisfa. Il BIP 360 è una proposta, non una regola, e l’elenco delle proposte aperte spetta alla lezione sulla governance.
Scegliere il tipo di indirizzo nel proprio wallet
Molti wallet permettono di scegliere SegWit nativo (bc1q) o Taproot (bc1p) per ricevere, e alcuni offrono ancora i tipi annidato (3…) e legacy (1…). Tutti e quattro restano validi e spendibili; nessuna regola li mette in pensione. La tabella delle dimensioni dà il compromesso sulle commissioni e la sezione precedente l’unico costo che Taproot aggiunge, una chiave sulla catena mentre le monete aspettano. Prima di cambiare conviene un ultimo controllo: assicurarsi che le persone o i servizi che ti pagano possano inviare al tipo che scegli. Un mittente che rifiuta un indirizzo bc1p di solito usa un software senza bech32m, non ha davanti un errore di battitura.
Spostare vecchie monete verso un tipo di indirizzo più recente è una transazione verso se stessi, e paga una commissione come ogni altra. Per chi vive in Italia, l’Agenzia delle Entrate indica, nella brochure sulla legge di bilancio 2025, l’imposta del 33% sulle plusvalenze da cripto-attività realizzate dal 1° gennaio 2026, senza soglia di esenzione; la nostra guida alle tasse sulle crypto in Italia spiega come si applica.
Cosa ricordare di SegWit e Taproot
- SegWit (2017) e Taproot (2021) sono soft fork che usano entrambi le versioni witness, output che i vecchi nodi trattano come spendibili da chiunque.
- SegWit ha spostato le firme fuori dal txid, il che ha posto fine alla malleabilità da parte di terzi per le spese SegWit e ha reso sicuro costruire i canali di pagamento.
- Taproot mette nell’output una chiave pubblica modificata; si può spendere con una sola firma Schnorr o rivelando uno script di un albero nascosto.
- Un output Taproot a chiave singola è più grande di uno SegWit nativo e il suo input è più piccolo; il vantaggio è più netto con chiavi condivise.
- I campioni di blocchi di Coindaro mostrano dati witness in circa nove transazioni su dieci o più nel 2026, e Taproot come tipo di minoranza la cui quota oscilla con le ondate di inscription.
La prossima lezione di questo percorso passa al Lightning Network, il sistema di canali di pagamento che dipende dagli ID di transazione fissi portati da SegWit.
