{"id":793,"date":"2026-10-15T16:40:30","date_gmt":"2026-10-15T16:40:30","guid":{"rendered":"https:\/\/hoge.gg\/it\/taproot-annex-si-risveglia-senza-fork-2026\/"},"modified":"2026-10-15T16:40:30","modified_gmt":"2026-10-15T16:40:30","slug":"taproot-annex-si-risveglia-senza-fork-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/it\/taproot-annex-si-risveglia-senza-fork-2026\/","title":{"rendered":"Taproot a cinque anni: l’annex si risveglia senza un fork"},"content":{"rendered":"

C’\u00e8 un campo nel protocollo di Bitcoin che esiste dal novembre 2021 e che, fino a poche settimane fa, non serviva a nulla. Si chiama annex<\/em>, vive nascosto nella struttura dei witness delle transazioni Taproot e, per quasi cinque anni, i nodi di Bitcoin Core lo hanno trattato come un ospite non gradito: le transazioni che lo contenevano non venivano propagate sulla rete. Era spazio riservato, lasciato apposta in bianco per un futuro che nessuno aveva ancora scritto.<\/p>

L’8 ottobre 2026 quel futuro ha bussato alla porta. Robin Linus, l’ideatore di BitVM, ha aperto la pull request numero 36466 sul repository di Bitcoin Core con un titolo asciutto: rendere standard gli annex Taproot non strutturati. Tradotto: smettere di cestinare le transazioni che usano quel campo e iniziare a propagarle. Non \u00e8 un soft fork, non cambia le regole di consenso e non richiede il voto dei miner. \u00c8 una modifica alla politica di propagazione, il tipo di aggiustamento che a Bitcoin capita di rado di vedere con una posta in gioco cos\u00ec alta.<\/p>

Dietro quelle poche righe di codice c’\u00e8 molto pi\u00f9 di una pulizia tecnica. C’\u00e8 un protocollo chiamato Glass Coins che promette transazioni private e compresse su Bitcoin; c’\u00e8 la coda lunga del dibattito su quali dati meritino spazio nei blocchi; e c’\u00e8 una domanda che accompagna Taproot fin dal primo giorno: a cosa serve davvero un aggiornamento che quasi nessuno usa? A cinque anni dall’attivazione, questa \u00e8 la storia di come il pezzo pi\u00f9 dimenticato di Taproot sia diventato, all’improvviso, il pi\u00f9 discusso.<\/p>

L’8 ottobre: dentro la pull request 36466<\/h2>

La pull request 36466<\/a>, aperta l’8 ottobre 2026, porta un titolo che dice tutto e niente: policy: make unstructured Taproot annexes standard<\/em>. L’autore \u00e8 Robin Linus, lo sviluppatore noto soprattutto per BitVM, l’architettura che permette di eseguire calcoli complessi su Bitcoin senza modificarne il consenso. La proposta tocca un solo aspetto del software: la politica di propagazione e di inclusione nei blocchi, cio\u00e8 quali transazioni un nodo accetta di ritrasmettere ai suoi pari e di tenere nel mempool.<\/p>

\u00c8 una distinzione che a Bitcoin conta moltissimo. Una modifica di consenso (come fu Taproot stesso) richiede che l’intera rete concordi, pena una frattura della catena. Una modifica di policy, invece, \u00e8 una scelta locale di ciascun nodo: chi aggiorna propaga le nuove transazioni, chi non aggiorna semplicemente le ignora, e nessuno viene espulso dalla rete. Rendere standard l’annex significa, in pratica, togliere un filtro che per cinque anni ha impedito a quelle transazioni di viaggiare.<\/p>

La proposta non \u00e8 arrivata nel vuoto. Come riporta la newsletter tecnica Last Week in Bitcoin<\/a>, due implementazioni alternative dei nodi, Libre Relay e rbitcoin, gi\u00e0 propagano gli annex da tempo; la PR di Linus prova a portare quella pratica dentro il client di riferimento. E ha raccolto subito attenzione qualificata: Peter Todd, storico collaboratore di Bitcoin Core, ha lasciato un utACK<\/em> (un via libera tecnico, non una verifica esaustiva) su uno dei commit, segnale che la proposta non \u00e8 un esperimento isolato ma un oggetto di revisione serio.<\/p>

Taproot in breve: cosa cambi\u00f2 nel novembre 2021<\/h2>

Per capire perch\u00e9 l’annex conta, serve un passo indietro. Taproot si \u00e8 attivato al blocco 709.632, il 14 novembre 2021, dopo un percorso di attivazione chiamato Speedy Trial: i miner avevano bloccato l’aggiornamento al blocco 687.284 del 12 giugno 2021, con oltre il 90% dei blocchi a segnalare il consenso, come documenta la pagina di riferimento sul wiki di Bitcoin<\/a>. Fu l’ultimo grande soft fork della rete e mise insieme tre proposte di miglioramento (BIP) distinte ma complementari.<\/p>

BIP<\/th>Nome<\/th>Cosa introduce<\/th><\/tr><\/thead>
340<\/td>Firme Schnorr<\/td>Firme da 64 byte, lineari e aggregabili con schemi come MuSig2<\/td><\/tr>
341<\/td>Taproot e MAST<\/td>Albero di Merkle delle condizioni di spesa e indirizzi P2TR (bc1p)<\/td><\/tr>
342<\/td>Tapscript<\/td>Linguaggio di script ridisegnato per Schnorr e per la verifica in batch<\/td><\/tr><\/tbody><\/table><\/figure>

Il cuore del cambiamento \u00e8 nelle firme Schnorr: pi\u00f9 compatte della vecchia firma ECDSA e, soprattutto, lineari. Questa propriet\u00e0 matematica permette di aggregare pi\u00f9 chiavi in una sola tramite schemi come MuSig2, cos\u00ec che un portafoglio multifirma complesso appaia sulla catena come un banale pagamento a chiave singola. MAST fa qualcosa di simile per le condizioni di spesa: nasconde tutti i rami non utilizzati e rivela solo quello effettivamente eseguito. Il risultato combinato \u00e8 un guadagno di privacy e, nei casi complessi, di spazio: una spesa Taproot via key path<\/em> \u00e8 indistinguibile da qualsiasi altra.<\/p>

Gli indirizzi Taproot, quelli che iniziano con il prefisso bc1p nella codifica bech32m, sono il volto visibile di questo apparato. Ma Tapscript, il terzo pezzo, \u00e8 forse il pi\u00f9 lungimirante: un linguaggio di script ridisegnato attorno a Schnorr, pensato per la verifica in batch e per lasciare spazio a estensioni future. Ed \u00e8 proprio una di quelle estensioni lasciate in sospeso che oggi torna d’attualit\u00e0.<\/p>

Che cos’\u00e8 l’annex, il campo lasciato in bianco<\/h2>

L’annex \u00e8 un campo opzionale all’interno della struttura witness degli input Taproot (tecnicamente i segwit di versione 1). La documentazione di Bitcoin Optech<\/a> lo descrive senza giri di parole: un campo che al momento non ha alcuno scopo definito. Quando \u00e8 presente, qualsiasi firma dell’input deve impegnarsi anche sul suo valore, cos\u00ec che non possa essere alterato dopo la firma. Si riconosce perch\u00e9 inizia con il byte 0x50.<\/p>

Perch\u00e9 inserire nel protocollo un campo che non fa niente? Perch\u00e9 Taproot \u00e8 stato progettato per essere estendibile. Riservare spazio oggi significa poter aggiungere domani nuove funzioni senza toccare il consenso: una sorta di presa elettrica installata nel muro in attesa che qualcuno costruisca l’elettrodomestico giusto. Il problema \u00e8 che, finch\u00e9 quell’elettrodomestico non arriva, la presa resta scollegata: Bitcoin Core, nella sua configurazione predefinita, non propaga n\u00e9 include nei blocchi le transazioni che contengono un annex.<\/p>

Negli anni le idee su come usarlo non sono mancate: parametri di timelock che variano in funzione delle commissioni, impegni crittografici su interi template di transazione, meccanismi di protezione contro i replay in caso di fork. Il dibattito pratico si \u00e8 acceso attorno al 2023, quando l’ambiente di test Bitcoin Inquisition ha iniziato a sperimentare con il campo. Ma nessuna di quelle proposte aveva mai raggiunto la massa critica necessaria a giustificare un cambio di policy nel client principale.<\/p>

Perch\u00e9 l’annex era rimasto fuori dallo standard<\/h2>

La scelta di tenere l’annex fuori dalle transazioni standard non \u00e8 stata una svista, ma una cautela deliberata. In Bitcoin esiste una differenza netta tra ci\u00f2 che \u00e8 valido secondo le regole di consenso e ci\u00f2 che \u00e8 standard<\/em>, cio\u00e8 che i nodi accettano di propagare di default. Una transazione con annex \u00e8 sempre stata, tecnicamente, valida: se un miner avesse voluto includerla in un blocco, la rete l’avrebbe accettata. Semplicemente, quella transazione non sarebbe mai arrivata fino al miner, perch\u00e9 i nodi lungo il percorso si rifiutavano di inoltrarla.<\/p>

Questo filtro di propagazione \u00e8 uno degli strumenti pi\u00f9 sottili della governance tecnica di Bitcoin. Serve a scoraggiare usi non ancora compresi, a proteggere la rete da comportamenti imprevisti e a lasciare agli sviluppatori il tempo di studiare le implicazioni di una nuova funzione prima che diventi di uso comune. Lasciare l’annex non standard significava, in sostanza, dire: esiste, \u00e8 pronto, ma non vogliamo ancora che qualcuno lo usi sul serio.<\/p>

La conseguenza \u00e8 che per quasi cinque anni l’annex \u00e8 rimasto una curiosit\u00e0 da specialisti, citata nei paper e nei forum ma invisibile nella pratica. Perch\u00e9 qualcuno si prendesse la briga di cambiare questa situazione serviva un caso d’uso concreto, abbastanza convincente da valere la discussione. Quel caso d’uso, nell’ottobre 2026, ha un nome: Glass Coins.<\/p>

Come funziona la proposta di Robin Linus<\/h2>

La PR 36466<\/a> non spalanca la porta a qualsiasi uso dell’annex: la apre di uno spiraglio, con regole precise. Sono resi standard solo due formati: un annex composto dal solo marcatore 0x50, che funziona come un semplice segnale di adesione, e la sequenza 0x50 0x00 seguita da dati arbitrari. Tutti gli altri prefissi dopo lo 0x50 restano non standard, cio\u00e8 riservati a usi futuri ancora da definire. \u00c8 un approccio volutamente conservativo: si apre il minimo indispensabile.<\/p>

Contenuto del campo<\/th>Stato proposto<\/th>Nota<\/th><\/tr><\/thead>
Nessun annex<\/td>Standard<\/td>Comportamento attuale della rete<\/td><\/tr>
0x50 (solo marcatore)<\/td>Standard, opt-in<\/td>Segnala l’adesione all’uso dell’annex<\/td><\/tr>
0x50 0x00 e dati arbitrari<\/td>Standard<\/td>Contenitore per i dati, ad esempio il nullifier<\/td><\/tr>
Altri prefissi dopo 0x50<\/td>Non standard<\/td>Riservati a usi futuri<\/td><\/tr>
Input P2A (pay-to-anchor)<\/td>Esente<\/td>Il witness deve restare vuoto<\/td><\/tr><\/tbody><\/table><\/figure>

La regola pi\u00f9 interessante \u00e8 quella che la proposta chiama, in sostanza, del tutto o niente: in una transazione, o tutti gli input diversi dai P2A portano un annex, oppure nessuno di essi pu\u00f2 farlo (gli input P2A, i pay-to-anchor usati per il fee bumping, devono invece avere un witness vuoto). Il motivo \u00e8 la tutela di chi non ha scelto di partecipare. Nelle transazioni collaborative, dove pi\u00f9 soggetti firmano input diversi (si pensi a un coinjoin o a una costruzione a UTXO condiviso), questa regola impedisce che una parte attacchi unilateralmente un annex a cui le firme altrui dovrebbero comunque impegnarsi. Non viene introdotto alcun limite di dimensione specifico: vale il tetto standard di 400.000 unit\u00e0 di peso per transazione.<\/p>

Glass Coins e Shielded CSV: il vero obiettivo<\/h2>

Il motore dietro la proposta \u00e8 un protocollo nato come Shielded CSV e che oggi Linus chiama Glass Coins. Il paper originale, firmato da Jonas Nick, Liam Eagen e Robin Linus con il contributo di Alpen Labs e ZeroSync, \u00e8 pubblico sull’archivio IACR<\/a>. L’idea sta nella sigla CSV: client-side validation<\/em>, validazione lato client. Invece di trasmettere ogni transazione a tutta la rete perch\u00e9 la verifichi, il mittente invia le monete al destinatario insieme a una prova di validit\u00e0. \u00c8 il destinatario, e solo lui, a dover controllare quella prova.<\/p>

La parte che tocca Bitcoin \u00e8 minima e chirurgica. Per impedire la doppia spesa, il protocollo deve scrivere sulla catena un piccolo dato chiamato nullifier<\/em>: appena 64 byte, come spiega l’approfondimento di Blockstream<\/a>, del tutto privi di significato per chi guarda il registro pubblico. Ogni nodo deve solo verificare una firma Schnorr per ciascun nullifier; chi non usa il protocollo pu\u00f2 ignorare quel dato del tutto. Ed \u00e8 qui che entra l’annex: \u00e8 il contenitore ideale per depositare quel nullifier sulla catena, ed \u00e8 questa la ragione concreta per cui Linus chiede di renderlo standard.<\/p>

I numeri che il protocollo promette sono notevoli. Una transazione tradizionale occupa in media circa 560 unit\u00e0 di peso; con Shielded CSV si scende verso le 64, una compressione di circa 8,75 volte che, almeno sulla carta, porterebbe la capacit\u00e0 teorica di Bitcoin da una decina di transazioni al secondo verso il centinaio. Non meno importante \u00e8 la privacy: a differenza di protocolli di validazione lato client precedenti come RGB o Taproot Assets, dove mittente e destinatario possono ricostruire l’intera storia delle monete, Shielded CSV usa schemi simili agli zk-SNARK per comprimere le prove e nascondere del tutto il grafo delle transazioni.<\/p>

Non sorprende l’entusiasmo dei suoi autori. Presentando il protocollo sulla mailing list bitcoindev<\/a>, Jonas Nick ha ripreso una definizione dello stesso Linus: Shielded CSV \u00e8 \u00abla cosa pi\u00f9 interessante che si possa fare con BitVM\u00bb. Un giudizio di parte, certo, ma che inquadra bene le ambizioni del progetto.<\/p>

BitVM, prove a conoscenza zero e la rete pi\u00f9 peer-to-peer<\/h2>

La connessione con BitVM non \u00e8 casuale. Shielded CSV \u00e8 definito attorno all’astrazione della proof-carrying data<\/em>, le prove che si portano dietro i propri dati, istanziabile tramite zk-SNARK ricorsivi o schemi di folding. In parole povere, ogni moneta viaggia accompagnata da una dimostrazione matematica compatta che ne attesta la legittimit\u00e0 risalendo a ritroso la catena di propriet\u00e0, senza per\u00f2 rivelarla. \u00c8 lo stesso tipo di macchinario crittografico che alimenta i rollup costruiti su Bitcoin senza chiedere un nuovo fork<\/a>, e non \u00e8 un caso che a tirare le fila sia sempre lo stesso ambiente di ricerca.<\/p>

C’\u00e8 per\u00f2 un limite onesto da segnalare, e gli stessi documenti del progetto lo ammettono: collegare in modo pienamente trustless Shielded CSV a Bitcoin, cio\u00e8 permettere di entrare e uscire dal sistema senza affidarsi a un intermediario, \u00e8 ancora materia di ricerca. Oggi quel ponte richiede federazioni o custodi fidati, e BitVM \u00e8 indicato come la strada per renderlo, un domani, senza fiducia. \u00c8 la stessa tensione tra promessa teorica e maturit\u00e0 pratica che attraversa tutto il mondo della crittografia verificabile.<\/p>

Resta il fatto che la filosofia di fondo \u00e8 coerente con lo spirito originario di Bitcoin. Spostare la verifica dal pubblico al privato, far s\u00ec che solo chi riceve una moneta debba controllarla, rende la rete, paradossalmente, ancora pi\u00f9 peer-to-peer di quanto non sia oggi, dove ogni nodo convalida tutto ci\u00f2 che accade a tutti. L’annex, in questo quadro, \u00e8 il minuscolo appiglio on-chain che tiene insieme un’architettura quasi interamente fuori catena.<\/p>

Il nodo dei dati on-chain: la lezione di OP_RETURN<\/h2>

Ogni volta che qualcuno propone di scrivere nuovi tipi di dati sulla catena di Bitcoin, si riapre una ferita che il 2025 aveva reso dolorosa. Con la versione 30.0 di Bitcoin Core, rilasciata il 10 ottobre 2025, il limite storico di 83 byte sugli output OP_RETURN \u00e8 stato di fatto cancellato: il parametro predefinito \u00e8 salito a 100.000 byte, e sono diventati standard anche pi\u00f9 output OP_RETURN nella stessa transazione. Per una parte della comunit\u00e0 \u00e8 stata una resa allo spam; per un’altra, come sintetizza l’analisi di Spark<\/a>, un atto di realismo.<\/p>

La reazione non si \u00e8 fatta attendere. La proposta BIP-110 ha cercato di riportare quei limiti dentro le regole di consenso, dove nessun singolo rilascio software potrebbe pi\u00f9 rimuoverli. Ma, come ha raccontato The Block<\/a>, il sostegno dei miner si \u00e8 fermato al 2,53% dei blocchi contro una soglia del 55%, e la catena alternativa che ne \u00e8 derivata ha prodotto appena due blocchi all’altezza 961.632, l’8 agosto 2026, per poi arenarsi. La frattura culturale tra Bitcoin Core e l’implementazione Knots \u00e8 rimasta, ben oltre i numeri.<\/p>

\u00c8 in questo clima che va letta la proposta sull’annex. Chi teme la deriva dei dati arbitrari vede un’altra porta che si apre; chi la difende fa notare una differenza sostanziale. Un’iscrizione in stile Ordinals pu\u00f2 pesare decine o centinaia di migliaia di byte tra immagini e testo; un nullifier di Shielded CSV ne occupa 64, \u00e8 un dato strettamente finanziario e serve a impedire la doppia spesa, non a stampare un meme sulla blockchain. La stessa posizione espressa da Peter Todd durante la battaglia su OP_RETURN andava in questa direzione: meglio concentrare i dati in un campo dedicato e prevedibile che costringere la gente a nasconderli in luoghi peggiori per le prestazioni della rete.<\/p>

Il punto di fondo \u00e8 sempre lo stesso: lo spazio nei blocchi \u00e8 una risorsa scarsa e contesa, e ogni byte che vi finisce compete con gli altri per le commissioni. \u00c8 la stessa economia che rende la sicurezza di Bitcoin una vera e propria asta per l’energia e per lo spazio<\/a>: chi scrive sulla catena paga, e quel pagamento \u00e8, nel lungo periodo, ci\u00f2 che tiene in piedi il budget di sicurezza della rete. Un protocollo come Shielded CSV promette di ottenere di pi\u00f9 con molto meno, ma la domanda su chi decide cosa merita quello spazio resta aperta.<\/p>

Taproot a cinque anni: i numeri dell’adozione<\/h2>

Tutta questa effervescenza tecnica stride con un dato scomodo: Taproot, dopo cinque anni, \u00e8 ancora poco usato. La sua quota sul traffico di rete ha avuto una storia a montagne russe. Partita da circa l’1% subito dopo l’attivazione, \u00e8 schizzata fino a un picco attorno al 40% all’inizio del 2024, quando il boom di Ordinals e Runes ha riempito i blocchi di transazioni Taproot; Cryptopolitan<\/a> parlava a gennaio 2024 di una crescita dall’1% al 39% in un anno. Esaurita quella febbre, la quota \u00e8 ridiscesa.<\/p>

Periodo<\/th>Quota transazioni Taproot<\/th>Fattore trainante<\/th><\/tr><\/thead>
Fine 2021 (attivazione)<\/td>circa 1%<\/td>Lancio dell’aggiornamento<\/td><\/tr>
Inizio 2024<\/td>picco intorno al 40%<\/td>Boom di Ordinals e Runes<\/td><\/tr>
2026<\/td>circa un quinto<\/td>Adozione organica dei wallet<\/td><\/tr><\/tbody><\/table><\/figure>

Oggi, secondo i tracker di adozione come quello di Spark<\/a>, Taproot vale all’incirca un quinto dell’attivit\u00e0, a seconda di come la si misura (indirizzi che ricevono fondi, transazioni con almeno un input Taproot, quota sugli output totali). Per fare un confronto, il pi\u00f9 anziano SegWit \u00e8 presente in circa l’85-90% delle transazioni: \u00e8 lo standard di fatto, e Taproot fatica a scalzarlo. Le cifre vanno prese con prudenza, perch\u00e9 ogni dashboard conta in modo diverso, ma la direzione \u00e8 chiara.<\/p>

Il paradosso \u00e8 evidente: mentre gli sviluppatori discutono di come spremere dall’infrastruttura Taproot funzioni avanzatissime come la validazione lato client, la stragrande maggioranza degli utenti non usa nemmeno un indirizzo bc1p. Capire perch\u00e9 richiede di guardare dove Bitcoin incontra davvero le persone: i portafogli e gli exchange.<\/p>

Perch\u00e9 wallet ed exchange restano indietro<\/h2>

Il freno all’adozione \u00e8 meno tecnico e pi\u00f9 pratico di quanto si pensi. Molti tra gli exchange pi\u00f9 grandi continuano a generare indirizzi di deposito SegWit, creando un attrito per chi vorrebbe consolidare tutto in un unico portafoglio Taproot. I wallet, dal canto loro, impostano quasi sempre come predefinito il SegWit nativo (P2WPKH) per i nuovi account, lasciando a Taproot il ruolo di opzione da selezionare a mano. Alcuni, come Blockstream Green, a met\u00e0 2026 non offrivano ancora il pieno supporto alla ricezione su indirizzi Taproot.<\/p>

C’\u00e8 poi la questione dell’incentivo. Per un pagamento a chiave singola, il risparmio di commissioni rispetto al SegWit nativo \u00e8 modesto: una firma Schnorr occupa 64 byte, poco meno di quanto serva a una firma tradizionale con la sua chiave pubblica. Il vantaggio diventa sostanziale solo nelle configurazioni multifirma, dove l’aggregazione delle chiavi riduce in modo sensibile l’impronta della transazione. Per l’utente medio, che non gestisce multisig complessi, il guadagno percepito \u00e8 quasi nullo.<\/p>

Il risultato \u00e8 il classico problema dell’uovo e della gallina: gli utenti non adottano Taproot perch\u00e9 gli sviluppatori non lo implementano come impostazione predefinita, e gli sviluppatori non lo rendono predefinito perch\u00e9 gli utenti non lo richiedono. Chi si occupa di autocustodia<\/a> sa quanto siano vischiose queste abitudini: cambiare il tipo di indirizzo predefinito tocca compatibilit\u00e0, backup e integrazioni con terze parti. E gli operatori istituzionali, dalle piattaforme di scambio alle banche che iniziano a custodire cripto<\/a>, si muovono con la prudenza di chi deve garantire continuit\u00e0 a milioni di clienti.<\/p>

Un cambiamento senza fork: come Bitcoin aggiorna le regole<\/h2>

La vicenda dell’annex \u00e8 istruttiva anche per il come, non solo per il cosa. Taproot richiese un soft fork, con tutto il peso politico di un’attivazione coordinata tra miner, nodi e portafogli. La proposta di Linus, invece, non tocca il consenso: \u00e8 una modifica di policy che ciascun operatore di nodo pu\u00f2 adottare o rifiutare individualmente. Se un numero sufficiente di nodi aggiorna, le transazioni con annex si propagano e i miner finiscono per includerle, senza che nessuno abbia mai dovuto votare un fork.<\/p>

\u00c8 il modo in cui Bitcoin, sempre pi\u00f9 spesso, prova a evolvere: non con grandi aggiornamenti monolitici, ma con aggiustamenti incrementali di ci\u00f2 che i nodi accettano di fare. Questo approccio ha un pregio, la riduzione del rischio sistemico, e un difetto, la frammentazione: implementazioni e configurazioni diverse possono divergere su cosa propagare, come ha mostrato proprio lo scontro tra Core e Knots. La propagazione, un tempo dettaglio da ingegneri, \u00e8 diventata un campo di battaglia politico.<\/p>

Sullo sfondo restano i cantieri pi\u00f9 ambiziosi e divisivi, quelli che un soft fork lo richiederebbero davvero. Il dibattito sulla resistenza quantistica, per esempio, ipotizza da tempo di limitare o disattivare in futuro la spesa via key path di Taproot, proprio il meccanismo che ne garantisce privacy ed efficienza, in cambio di una maggiore protezione contro i computer quantistici. Rispetto a quelle discussioni, rendere standard l’annex \u00e8 un intervento quasi indolore. Ed \u00e8 anche per questo che ha qualche possibilit\u00e0 concreta di passare.<\/p>

Rischi, obiezioni e scenari possibili<\/h2>

Nessuna proposta del genere \u00e8 priva di contropartite. La prima obiezione \u00e8 culturale e la conosciamo: ogni allargamento di ci\u00f2 che \u00e8 standard viene letto da una parte della comunit\u00e0 come un invito a riempire i blocchi di dati non finanziari. Il formato 0x50 0x00 seguito da dati arbitrari, in teoria, potrebbe ospitare anche contenuti che con la doppia spesa non c’entrano nulla. I sostenitori rispondono che la regola del tutto o niente e l’assenza di un limite dedicato (resta solo quello generale di 400.000 unit\u00e0 di peso) rendono l’annex poco attraente per l’abuso rispetto al ben pi\u00f9 capiente OP_RETURN.<\/p>

C’\u00e8 poi un rischio di maturit\u00e0. Shielded CSV \u00e8 un protocollo recente, la cui sicurezza poggia su schemi crittografici sofisticati (zk-SNARK ricorsivi, folding) ancora in rodaggio, e il cui ponte verso Bitcoin \u00e8, oggi, fidato. Standardizzare l’annex non rende magicamente pronto l’ecosistema che dovrebbe sfruttarlo: \u00e8 una condizione necessaria, non sufficiente. Esiste il rischio concreto che la PR venga accettata e che, per anni, l’annex resti comunque poco usato, esattamente come \u00e8 successo a Taproot nel suo complesso.<\/p>

Lo scenario pi\u00f9 probabile nel breve periodo \u00e8 quello di una lunga revisione tecnica. L’utACK di Peter Todd \u00e8 un buon segno, ma una modifica di policy con implicazioni di questa portata raccoglier\u00e0 obiezioni, controproposte e richieste di test prima di un eventuale merge. Nel frattempo, i nodi che gi\u00e0 oggi propagano gli annex, come Libre Relay, continueranno a fare da apripista. Se e quando Glass Coins mostrer\u00e0 transazioni reali in produzione, la pressione per lo standard aumenter\u00e0; se invece rester\u00e0 confinato ai paper, l’annex torner\u00e0 a dormire.<\/p>

Cosa cambia per chi detiene bitcoin in Italia<\/h2>

Per il detentore italiano, l’impatto immediato di tutto questo \u00e8 prossimo allo zero, ed \u00e8 giusto dirlo senza enfasi. L’annex \u00e8 una modifica di rete, fuori dal perimetro di vigilanza di Consob, che non riguarda il valore o la detenzione di bitcoin ma il modo in cui alcune transazioni viaggiano tra i nodi. Al cambio attuale, con un bitcoin che vale intorno ai 72.000 euro<\/a> dopo la brusca correzione di met\u00e0 ottobre, nessuna di queste novit\u00e0 sposta di un centesimo il portafoglio di chi semplicemente conserva BTC.<\/p>

Le cose cambiano un po’ per chi usa Bitcoin attivamente. Protocolli come Shielded CSV promettono, un domani, transazioni pi\u00f9 private ed economiche: una prospettiva interessante in un paese dove ogni operazione ha anche un risvolto fiscale. Vale la pena ricordare che l’Italia applica alle plusvalenze cripto un’aliquota tra le pi\u00f9 alte d’Europa<\/a>, e che una maggiore privacy a livello di protocollo non cambia gli obblighi di dichiarazione: la riservatezza tecnica e la trasparenza fiscale restano due piani distinti.<\/p>

Il consiglio pratico, semmai, \u00e8 a monte: per sfruttare gi\u00e0 oggi i vantaggi di Taproot (privacy delle condizioni di spesa, risparmio sui multisig) occorre un portafoglio che generi indirizzi bc1p e li usi anche in ricezione, non solo in invio. \u00c8 una scelta alla portata di chiunque gestisca la propria autocustodia, e non richiede di attendere n\u00e9 l’annex n\u00e9 i Glass Coins. Il resto, per ora, \u00e8 un cantiere per sviluppatori; ma \u00e8 un cantiere che, dopo cinque anni di quiete, ha ricominciato a fare rumore.<\/p>

Domande frequenti<\/h2>

Che cos’\u00e8 l’annex di Taproot?<\/h3>

L’annex \u00e8 un campo opzionale nella struttura witness degli input Taproot, introdotto nel novembre 2021 ma lasciato senza uno scopo definito. Si riconosce dal byte iniziale 0x50 e, fino alla proposta dell’ottobre 2026, Bitcoin Core non propagava le transazioni che lo contenevano, trattandolo come spazio riservato a usi futuri.<\/p>

La proposta sull’annex \u00e8 un soft fork di Bitcoin?<\/h3>

No. La pull request 36466 modifica solo la politica di propagazione, cio\u00e8 quali transazioni i nodi ritrasmettono di default. Non cambia le regole di consenso e non richiede un’attivazione coordinata tra miner e nodi come avvenne per Taproot. Ogni operatore di nodo pu\u00f2 adottare o ignorare la modifica individualmente, senza rischio di frattura della catena.<\/p>

Cosa sono i Glass Coins e lo Shielded CSV?<\/h3>

Shielded CSV, oggi chiamato Glass Coins, \u00e8 un protocollo di validazione lato client sviluppato da Jonas Nick, Liam Eagen e Robin Linus. Permette di inviare monete insieme a una prova di validit\u00e0, scrivendo sulla catena solo un piccolo dato da 64 byte, il nullifier, per impedire la doppia spesa. Promette transazioni molto pi\u00f9 compatte e una privacy che nasconde del tutto il grafo delle operazioni.<\/p>

Perch\u00e9 l’adozione di Taproot \u00e8 cos\u00ec lenta?<\/h3>

Per un insieme di attriti pratici: molti exchange generano ancora indirizzi di deposito SegWit, la maggior parte dei wallet usa SegWit nativo come impostazione predefinita e per i pagamenti a chiave singola il risparmio offerto da Taproot \u00e8 modesto. Il vantaggio \u00e8 reale soprattutto nei multisig. Ne risulta un classico problema dell’uovo e della gallina che tiene l’adozione intorno a un quinto del traffico.<\/p>

Conviene usare un indirizzo Taproot bc1p nel 2026?<\/h3>

Per la maggior parte degli utenti \u00e8 una scelta ragionevole, soprattutto con configurazioni multifirma dove i vantaggi di risparmio e privacy sono concreti. Serve per\u00f2 un portafoglio che supporti la ricezione su indirizzi bc1p e occorre verificare che le controparti sappiano inviare a quel formato. Per un semplice pagamento a chiave singola, il guadagno rispetto al SegWit nativo \u00e8 minimo.<\/p>