Taproot a cinque anni: l’annex si risveglia senza un fork

C’è 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, 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.

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 è un soft fork, non cambia le regole di consenso e non richiede il voto dei miner. È una modifica alla politica di propagazione, il tipo di aggiustamento che a Bitcoin capita di rado di vedere con una posta in gioco così alta.

Dietro quelle poche righe di codice c’è molto più di una pulizia tecnica. C’è un protocollo chiamato Glass Coins che promette transazioni private e compresse su Bitcoin; c’è la coda lunga del dibattito su quali dati meritino spazio nei blocchi; e c’è 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 è la storia di come il pezzo più dimenticato di Taproot sia diventato, all’improvviso, il più discusso.

L’8 ottobre: dentro la pull request 36466

La pull request 36466, aperta l’8 ottobre 2026, porta un titolo che dice tutto e niente: policy: make unstructured Taproot annexes standard. L’autore è 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è quali transazioni un nodo accetta di ritrasmettere ai suoi pari e di tenere nel mempool.

È 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, è 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.

La proposta non è arrivata nel vuoto. Come riporta la newsletter tecnica Last Week in Bitcoin, due implementazioni alternative dei nodi, Libre Relay e rbitcoin, già 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 (un via libera tecnico, non una verifica esaustiva) su uno dei commit, segnale che la proposta non è un esperimento isolato ma un oggetto di revisione serio.

Taproot in breve: cosa cambiò nel novembre 2021

Per capire perché l’annex conta, serve un passo indietro. Taproot si è 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. Fu l’ultimo grande soft fork della rete e mise insieme tre proposte di miglioramento (BIP) distinte ma complementari.

Il cuore del cambiamento è nelle firme Schnorr: più compatte della vecchia firma ECDSA e, soprattutto, lineari. Questa proprietà matematica permette di aggregare più chiavi in una sola tramite schemi come MuSig2, così 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 è un guadagno di privacy e, nei casi complessi, di spazio: una spesa Taproot via key path è indistinguibile da qualsiasi altra.

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, è forse il più lungimirante: un linguaggio di script ridisegnato attorno a Schnorr, pensato per la verifica in batch e per lasciare spazio a estensioni future. Ed è proprio una di quelle estensioni lasciate in sospeso che oggi torna d’attualità.

Che cos’è l’annex, il campo lasciato in bianco

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

Perché inserire nel protocollo un campo che non fa niente? Perché Taproot è 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 è che, finché quell’elettrodomestico non arriva, la presa resta scollegata: Bitcoin Core, nella sua configurazione predefinita, non propaga né include nei blocchi le transazioni che contengono un annex.

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 è 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.

Perché l’annex era rimasto fuori dallo standard

La scelta di tenere l’annex fuori dalle transazioni standard non è stata una svista, ma una cautela deliberata. In Bitcoin esiste una differenza netta tra ciò che è valido secondo le regole di consenso e ciò che è standard, cioè che i nodi accettano di propagare di default. Una transazione con annex è 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é i nodi lungo il percorso si rifiutavano di inoltrarla.

Questo filtro di propagazione è uno degli strumenti più 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, è pronto, ma non vogliamo ancora che qualcuno lo usi sul serio.

La conseguenza è che per quasi cinque anni l’annex è rimasto una curiosità da specialisti, citata nei paper e nei forum ma invisibile nella pratica. Perché 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.

Come funziona la proposta di Robin Linus

La PR 36466 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è riservati a usi futuri ancora da definire. È un approccio volutamente conservativo: si apre il minimo indispensabile.

La regola più interessante è 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ò farlo (gli input P2A, i pay-to-anchor usati per il fee bumping, devono invece avere un witness vuoto). Il motivo è la tutela di chi non ha scelto di partecipare. Nelle transazioni collaborative, dove più 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à di peso per transazione.

Glass Coins e Shielded CSV: il vero obiettivo

Il motore dietro la proposta è 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, è pubblico sull’archivio IACR. L’idea sta nella sigla CSV: client-side validation, validazione lato client. Invece di trasmettere ogni transazione a tutta la rete perché la verifichi, il mittente invia le monete al destinatario insieme a una prova di validità. È il destinatario, e solo lui, a dover controllare quella prova.

La parte che tocca Bitcoin è minima e chirurgica. Per impedire la doppia spesa, il protocollo deve scrivere sulla catena un piccolo dato chiamato nullifier: appena 64 byte, come spiega l’approfondimento di Blockstream, 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ò ignorare quel dato del tutto. Ed è qui che entra l’annex: è il contenitore ideale per depositare quel nullifier sulla catena, ed è questa la ragione concreta per cui Linus chiede di renderlo standard.

I numeri che il protocollo promette sono notevoli. Una transazione tradizionale occupa in media circa 560 unità di peso; con Shielded CSV si scende verso le 64, una compressione di circa 8,75 volte che, almeno sulla carta, porterebbe la capacità teorica di Bitcoin da una decina di transazioni al secondo verso il centinaio. Non meno importante è 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.

Non sorprende l’entusiasmo dei suoi autori. Presentando il protocollo sulla mailing list bitcoindev, Jonas Nick ha ripreso una definizione dello stesso Linus: Shielded CSV è «la cosa più interessante che si possa fare con BitVM». Un giudizio di parte, certo, ma che inquadra bene le ambizioni del progetto.

BitVM, prove a conoscenza zero e la rete più peer-to-peer

La connessione con BitVM non è casuale. Shielded CSV è definito attorno all’astrazione della proof-carrying data, 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à risalendo a ritroso la catena di proprietà, senza però rivelarla. È lo stesso tipo di macchinario crittografico che alimenta i rollup costruiti su Bitcoin senza chiedere un nuovo fork, e non è un caso che a tirare le fila sia sempre lo stesso ambiente di ricerca.

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

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

Il nodo dei dati on-chain: la lezione di OP_RETURN

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 è stato di fatto cancellato: il parametro predefinito è salito a 100.000 byte, e sono diventati standard anche più output OP_RETURN nella stessa transazione. Per una parte della comunità è stata una resa allo spam; per un’altra, come sintetizza l’analisi di Spark, un atto di realismo.

La reazione non si è fatta attendere. La proposta BIP-110 ha cercato di riportare quei limiti dentro le regole di consenso, dove nessun singolo rilascio software potrebbe più rimuoverli. Ma, come ha raccontato The Block, il sostegno dei miner si è fermato al 2,53% dei blocchi contro una soglia del 55%, e la catena alternativa che ne è 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 è rimasta, ben oltre i numeri.

È 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ò pesare decine o centinaia di migliaia di byte tra immagini e testo; un nullifier di Shielded CSV ne occupa 64, è 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.

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

Taproot a cinque anni: i numeri dell’adozione

Tutta questa effervescenza tecnica stride con un dato scomodo: Taproot, dopo cinque anni, è 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, è 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 parlava a gennaio 2024 di una crescita dall’1% al 39% in un anno. Esaurita quella febbre, la quota è ridiscesa.

Oggi, secondo i tracker di adozione come quello di Spark, Taproot vale all’incirca un quinto dell’attività, 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ù anziano SegWit è presente in circa l’85-90% delle transazioni: è lo standard di fatto, e Taproot fatica a scalzarlo. Le cifre vanno prese con prudenza, perché ogni dashboard conta in modo diverso, ma la direzione è chiara.

Il paradosso è 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é richiede di guardare dove Bitcoin incontra davvero le persone: i portafogli e gli exchange.

Perché wallet ed exchange restano indietro

Il freno all’adozione è meno tecnico e più pratico di quanto si pensi. Molti tra gli exchange più 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à 2026 non offrivano ancora il pieno supporto alla ricezione su indirizzi Taproot.

C’è poi la questione dell’incentivo. Per un pagamento a chiave singola, il risparmio di commissioni rispetto al SegWit nativo è 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 è quasi nullo.

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

Un cambiamento senza fork: come Bitcoin aggiorna le regole

La vicenda dell’annex è 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: è una modifica di policy che ciascun operatore di nodo può 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.

È il modo in cui Bitcoin, sempre più spesso, prova a evolvere: non con grandi aggiornamenti monolitici, ma con aggiustamenti incrementali di ciò 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, è diventata un campo di battaglia politico.

Sullo sfondo restano i cantieri più 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 è un intervento quasi indolore. Ed è anche per questo che ha qualche possibilità concreta di passare.

Rischi, obiezioni e scenari possibili

Nessuna proposta del genere è priva di contropartite. La prima obiezione è culturale e la conosciamo: ogni allargamento di ciò che è standard viene letto da una parte della comunità 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à di peso) rendono l’annex poco attraente per l’abuso rispetto al ben più capiente OP_RETURN.

C’è poi un rischio di maturità. Shielded CSV è un protocollo recente, la cui sicurezza poggia su schemi crittografici sofisticati (zk-SNARK ricorsivi, folding) ancora in rodaggio, e il cui ponte verso Bitcoin è, oggi, fidato. Standardizzare l’annex non rende magicamente pronto l’ecosistema che dovrebbe sfruttarlo: è 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 è successo a Taproot nel suo complesso.

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

Cosa cambia per chi detiene bitcoin in Italia

Per il detentore italiano, l’impatto immediato di tutto questo è prossimo allo zero, ed è giusto dirlo senza enfasi. L’annex è 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 dopo la brusca correzione di metà ottobre, nessuna di queste novità sposta di un centesimo il portafoglio di chi semplicemente conserva BTC.

Le cose cambiano un po’ per chi usa Bitcoin attivamente. Protocolli come Shielded CSV promettono, un domani, transazioni più 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ù alte d’Europa, 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.

Il consiglio pratico, semmai, è a monte: per sfruttare già 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. È una scelta alla portata di chiunque gestisca la propria autocustodia, e non richiede di attendere né l’annex né i Glass Coins. Il resto, per ora, è un cantiere per sviluppatori; ma è un cantiere che, dopo cinque anni di quiete, ha ricominciato a fare rumore.

Domande frequenti

Che cos’è l’annex di Taproot?

L’annex è 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.

La proposta sull’annex è un soft fork di Bitcoin?

No. La pull request 36466 modifica solo la politica di propagazione, cioè 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ò adottare o ignorare la modifica individualmente, senza rischio di frattura della catena.

Cosa sono i Glass Coins e lo Shielded CSV?

Shielded CSV, oggi chiamato Glass Coins, è 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à, scrivendo sulla catena solo un piccolo dato da 64 byte, il nullifier, per impedire la doppia spesa. Promette transazioni molto più compatte e una privacy che nasconde del tutto il grafo delle operazioni.

Perché l’adozione di Taproot è così lenta?

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 è modesto. Il vantaggio è reale soprattutto nei multisig. Ne risulta un classico problema dell’uovo e della gallina che tiene l’adozione intorno a un quinto del traffico.

Conviene usare un indirizzo Taproot bc1p nel 2026?

Per la maggior parte degli utenti è una scelta ragionevole, soprattutto con configurazioni multifirma dove i vantaggi di risparmio e privacy sono concreti. Serve però 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 è minimo.

A cura della redazione Bitcoin di HOGE Wire. Questo articolo ha finalità informative e non costituisce consulenza finanziaria.