Se hai aperto un portafoglio Bitcoin e ti è stato chiesto di scegliere tra un indirizzo "Legacy", "SegWit" o "Native SegWit" senza alcuna spiegazione sul significato di queste opzioni, tale scelta risale a un unico aggiornamento effettuato nel 2017.
SegWit, abbreviazione di Segregated Witness, è un aggiornamento del protocollo Bitcoin attivato nell'agosto 2017 che sposta i dati della firma digitale fuori dalla struttura principale della transazione e li colloca in un campo separato chiamato "witness". Quel singolo cambiamento architettonico ha ridotto le commissioni di transazione, ha risolto una vulnerabilità di sicurezza che durava da anni, nota come "malleabilità delle transazioni", e ha creato le condizioni tecniche per l'esistenza della Lightning Network e di Taproot.
Questo articolo spiega in cosa consiste effettivamente SegWit, come funziona il sistema del peso dei blocchi, quale impatto hanno i diversi tipi di indirizzo sulle commissioni e la controversa battaglia politica che ha rischiato di lacerare la rete Bitcoin prima ancora che venisse attivato.
Gestisci i tuoi Bitcoin con il App Portafoglio Bitcoin.com.
Punti chiave
- SegWit (Segregated Witness) è un aggiornamento del protocollo Bitcoin attivato il 24 agosto 2017, formalmente definito come BIP 141 e proposto da Pieter Wuille, Eric Lombrozo e Johnson Lau nel dicembre 2015.
- Separa i dati della firma digitale (il "witness") dal corpo principale della transazione, risolvendo una vulnerabilità di sicurezza nota come "malleabilità delle transazioni" e riducendo le dimensioni di ciascuna transazione.
- La capacità dei blocchi viene misurata in unità di peso (WU) anziché in byte. I dati dei testimoni occupano 1 WU per byte, contro le 4 WU per byte richieste dagli altri dati, garantendo alle transazioni SegWit uno sconto del 75% sulla dimensione della firma.
- Il SegWit nativo (indirizzi bc1q) riduce la dimensione di una transazione standard da circa 226 vbyte a circa 141 vbyte, con una diminuzione delle commissioni di circa il 38% rispetto agli indirizzi tradizionali.
- La garanzia di un TXID fisso offerta da SegWit era il presupposto tecnico fondamentale per la creazione della rete Lightning. Senza di essa, non sarebbe stato possibile creare in modo sicuro i canali di pagamento.
- Il suo sistema di gestione delle versioni degli script ha reso possibile l'implementazione di Taproot (SegWit V1, attivato nel 2021) e fornisce un quadro di riferimento per futuri aggiornamenti di Bitcoin senza hard fork.
- A partire dal 2026, circa l'85% delle transazioni in Bitcoin utilizza SegWit. Si tratta dello standard di rete, non di una nuova funzionalità.
Che cos'è SegWit?
SegWit, o Segregated Witness, è una modifica al formato delle transazioni di Bitcoin che separa le firme digitali – la prova crittografica del diritto di spendere una moneta – dai dati principali della transazione, memorizzandole in una struttura separata chiamata "witness". Questo rende ogni transazione più piccola, permette di inserire più transazioni in ogni blocco ed elimina una vulnerabilità che aveva reso impossibile costruire in modo sicuro canali di pagamento basati su Bitcoin.
Il nome si spiega facilmente: "segregated" significa "separato", mentre "witness" è il termine crittografico che indica i dati della firma che dimostrano la validità di una transazione. Il witness risponde alla domanda "il legittimo proprietario ha autorizzato questa operazione?", mentre il resto dei dati della transazione risponde "dove vanno a finire i fondi e per quale importo?".
The official BIP 141 header on GitHub, showing its three co-authors and December 2015 assignment date.L'aggiornamento è stato formalmente definito come Bitcoin Improvement Proposal 141 (BIP 141) e proposto dagli sviluppatori di Bitcoin Core Pieter Wuille, Eric Lombrozo e Johnson Lau alla conferenza Scaling Bitcoin nel dicembre 2015. È stato attivato sulla mainnet di Bitcoin il 24 agosto 2017, al blocco 481.824, come soft fork, il che significa che era retrocompatibile. I nodi che non avevano effettuato l'aggiornamento potevano comunque convalidare i dati di base della transazione; i nodi aggiornati vedevano il quadro completo, compreso il witness.
A partire dal 2026, circa l'85% di tutte le transazioni in Bitcoin utilizza SegWit. Non si tratta più di una novità, ma dello standard.
I problemi che SegWit è stato concepito per risolvere
SegWit ha risolto due problemi distinti che da anni rappresentavano un limite per Bitcoin.
Malleabilità delle transazioni
Ogni transazione Bitcoin ha un identificatore univoco chiamato TXID, un hash generato dai dati della transazione. Prima dell'introduzione di SegWit, tale hash veniva calcolato sull'intera transazione, compresa la firma.
Il problema è questo: una firma crittografica non può firmare se stessa. Ciò ha lasciato un piccolo margine di manovra che consentiva a chiunque, nel trasmettere la transazione attraverso la rete, di modificare leggermente la firma in modo tale da mantenerla matematicamente valida ma generando un TXID diverso. I fondi venivano comunque inviati all'indirizzo corretto e la transazione veniva comunque completata, ma l'identificatore era cambiato.
Per un semplice pagamento, la cosa non sembra così grave. Per i protocolli che concatenano più transazioni non confermate, invece, è fatale. La rete Lightning, che funziona creando una serie di impegni di pagamento off-chain che fanno riferimento a ID di transazioni precedenti, non può funzionare in modo sicuro se uno qualsiasi di questi ID può cambiare prima della conferma. Un TXID mutabile significa che la catena si interrompe e i fondi possono rimanere bloccati o essere rubati.
La malleabilità delle transazioni ha causato danni concreti prima di essere risolta. L'exchange Mt. Gox l'ha indicata come uno dei fattori che hanno contribuito al suo crollo nel 2014, anche se gli storici discutono su quanto essa sia stata la causa principale o piuttosto una scusa per nascondere una gestione ancora più disastrosa.
SegWit ha risolto il problema eliminando completamente le firme dal calcolo del TXID. L'identificatore viene ora calcolato esclusivamente sulla base dei campi della transazione. La modifica della firma non altera più l'identità della transazione.
Bloccare la congestione e l'aumento delle commissioni
Nel 2016 e all'inizio del 2017, Bitcoin elaborava circa 7 transazioni al secondo. Durante i picchi di domanda, gli arretrati delle transazioni raggiungevano le decine di migliaia e le commissioni salivano a 50 dollari o più per un invio standard. Il problema era strutturale: i blocchi di Bitcoin avevano un limite massimo di 1 MB e le firme costituivano circa il 65% della dimensione delle transazioni.
La soluzione più ovvia, ovvero aumentare il limite di dimensione dei blocchi, richiedeva un hard fork, il che significava che tutti i nodi avrebbero dovuto aggiornarsi o rimanere su una catena incompatibile. Gli hard fork sono operazioni ad alto rischio e controverse. SegWit ha trovato un modo per aggirare completamente questo vincolo.
Come funziona SegWit
Separazione dei dati relativi ai testimoni
In una transazione Bitcoin tradizionale, ogni input include un campo ScriptSig contenente la firma e la chiave pubblica del mittente. In una transazione SegWit, il campo ScriptSig viene lasciato vuoto per gli input SegWit. La firma e la chiave pubblica vengono spostate in un nuovo campo "witness" aggiunto alla fine della transazione.
Due byte aggiuntivi, un indicatore (0x00) e un flag (0x01), segnalano ai nodi compatibili con SegWit che seguono i dati del witness. I nodi precedenti a SegWit vedono semplicemente uno ScriptSig vuoto ed elaborano la transazione come valida secondo la vecchia interpretazione "chiunque può spendere", garantendo così la retrocompatibilità.
Il peso del blocco sostituisce la dimensione del blocco
SegWit ha sostituito il limite di dimensione dei blocchi di 1 MB con un nuovo parametro: il peso del blocco, con un limite massimo di 4 milioni di unità di peso (WU).
Il punto cruciale sta nel modo in cui vengono contati i byte:
- Ogni byte di dati relativi alle transazioni non witness costa 4 unità di peso
- Ogni byte di dati di riferimento costa solo 1 unità di peso
Poiché le firme occupano molto spazio e ora risiedono nella sezione witness, occupano un quarto dello spazio che occupavano in precedenza in termini di capacità del blocco. È così che SegWit ha aumentato la dimensione effettiva del blocco a circa 1,7-2 MB nella pratica, senza modificare la regola del 1 MB applicata dai nodi più vecchi. Per un blocco teoricamente interamente SegWit, il massimo è di 4 MB, anche se questo non si verifica mai nella pratica poiché ogni blocco contiene anche dati non witness.
Virtual Bytes (vBytes): l'unità che vedete nei portafogli
Per mantenere le commissioni comparabili a quelle delle transazioni tradizionali, SegWit ha introdotto i byte virtuali (vbyte): unità di peso divise per 4. Nelle transazioni tradizionali, byte e vbyte sono identici. Nelle transazioni SegWit, i vbyte sono inferiori perché i dati witness ridotti ne abbassano il valore.
Le commissioni dei portafogli sono espresse in satoshi per vbyte (sat/vB). Una transazione SegWit con un numero inferiore di vbyte comporta commissioni inferiori a parità di tasso sat/vB. Questo è il meccanismo alla base del risparmio sulle commissioni che si osserva quando si utilizza un indirizzo bc1q anziché un indirizzo 1...
Tipi di indirizzi SegWit: quale scegliere?
Oltre alle modifiche tecniche, SegWit ha introdotto nuovi formati di indirizzo. Il tipo di indirizzo determina il modo in cui il portafoglio codifica le condizioni di spesa, il che influisce sulle commissioni, sulla compatibilità con altri portafogli e sull'aspetto delle transazioni sulla blockchain.
Confronto tra i tipi di indirizzo
1...3...bc1q... 42 caratteribc1q... 62 caratteribc1p... 62 caratteri1...3...bc1q... 42 caratteribc1q... 62 caratteribc1p... 62 caratteriDati relativi all'entità delle transazioni: Spark.money: Riferimento sulle dimensioni delle transazioni Bitcoin, 2026. I risparmi sulle commissioni sono indicativi e variano a seconda delle condizioni del mempool.
Legacy (P2PKH, prefisso 1...) È il formato originale del 2009. La firma rimane all'interno del corpo principale della transazione, dove ha pieno peso. Nessun risparmio sulle commissioni. È ancora universalmente supportato, il che è l'unico motivo per utilizzarlo oggi, se si ha a che fare con software molto datato che non è in grado di gestire altro.
SegWit annidato (P2SH-P2WPKH, prefisso 3...) racchiude uno script SegWit all'interno di un involucro P2SH di vecchia generazione. Quando SegWit è stato attivato nel 2017, non tutti i portafogli e gli exchange hanno aggiunto immediatamente il supporto per il nuovo formato bc1. Il SegWit annidato ha fatto da ponte di compatibilità: si ottiene un risparmio parziale sulle commissioni e i mittenti che utilizzano software meno recenti possono comunque effettuare pagamenti. Entro il 2026, questo formato esiste principalmente come soluzione di ripiego. Il 3... Il prefisso è in comune con gli indirizzi P2SH non SegWit, il che significa che non è possibile capire, basandosi solo sull'indirizzo, se si tratta di una transazione SegWit.
SegWit nativo (P2WPKH, prefisso bc1q..., 42 caratteri) è la scelta giusta per la maggior parte degli utenti. Utilizza la codifica Bech32, che prevede solo lettere minuscole, offre un rilevamento degli errori migliore rispetto a Base58 ed elimina i caratteri che possono essere confusi (nessuna O maiuscola, zero, I maiuscola o l minuscola). Una transazione P2WPKH standard a 1 input e 2 output costa circa 141 vbyte, circa il 38% in meno rispetto alla transazione legacy equivalente. Tutti i portafogli e gli exchange attivi la supportano a partire dal 2026.
Multisig nativo SegWit (P2WSH, prefisso bc1q...(62 caratteri) è la variante con hash dello script, utilizzata per i portafogli multisig e le condizioni di spesa complesse. L'indirizzo più lungo riflette un hash SHA-256 a 32 byte anziché l'hash a 20 byte utilizzato da P2WPKH. Se stai utilizzando una configurazione multisig 2-di-3, P2WSH è il modo nativo di SegWit per farlo.
Taproot (P2TR, prefisso bc1p...(62 caratteri) Si tratta della versione 1 di SegWit, attivata nel 2021. Utilizza le firme Schnorr anziché ECDSA, il che consente di aggregare più firme in una sola, rendendo le transazioni multisig indistinguibili da quelle single-sig sulla blockchain. Offre le commissioni più basse per le spese single-sig e la massima privacy. Utilizzala quando hai verificato che i tuoi destinatari e i loro portafogli supportino gli indirizzi bc1p.
Consiglio veloce
Per la maggior parte degli utenti: utilizzate SegWit nativo (bc1q). È supportato praticamente da tutti i portafogli e le piattaforme di scambio attivi, consente un risparmio di circa il 38% sulle commissioni rispetto al sistema tradizionale e non comporta alcun rischio di incompatibilità nel 2026 (per gli sviluppatori che intendono integrare SegWit nel software dei portafogli, consultare il Guida allo sviluppo del portafoglio Bitcoin Core.).
Se il tuo portafoglio supporta Taproot (bc1p) ed effettui transazioni con firma singola verso destinatari i cui portafogli lo supportano, potrai beneficiare di commissioni leggermente inferiori e di una maggiore privacy.
Il SegWit annidato (3...) è una soluzione di ripiego per garantire la compatibilità. Va bene, ma non c'è più motivo di utilizzarlo come impostazione predefinita.
La guerra sulla dimensione dei blocchi: perché SegWit è stato così controverso
Dal punto di vista tecnico, i vantaggi di SegWit erano evidenti. Il percorso verso la sua attivazione, invece, non lo era.
Dal 2015 al 2017, Bitcoin è stato al centro di una delle controversie di governance più accese della sua storia. In sostanza, la questione era semplice: in che modo una rete decentralizzata dovrebbe aggiornare le proprie regole quando fazioni diverse hanno interessi contrastanti?
Lo stallo nel settore minerario
In base alla procedura standard di aggiornamento BIP9, un soft fork richiedeva che il 95% dei miner manifestasse il proprio sostegno entro un periodo di due settimane. All'inizio del 2017, SegWit era pronto per essere attivato già da mesi, ma rimaneva bloccato al di sotto di tale soglia.
L'opposizione più significativa proveniva dalle grandi operazioni di mining, in particolare da Bitmain, che all'epoca controllava una quota sostanziale dell'hashrate di Bitcoin. Il motivo è poi diventato chiaro: Bitmain utilizzava una tecnica brevettata chiamata ASICBoost, un'ottimizzazione che conferiva al suo hardware di mining un significativo vantaggio in termini di efficienza. SegWit era strutturalmente incompatibile con l'ASICBoost nascosto. Bloccare SegWit proteggeva quel vantaggio.
BIP 148 e l'UASF
Nel marzo 2017, uno sviluppatore anonimo che utilizzava lo pseudonimo Shaolinfry ha pubblicato il BIP 148: un soft fork attivato dagli utenti (UASF). Anziché attendere il segnale dei miner, il BIP 148 proponeva che i nodi economici, ovvero gli exchange, i processori di pagamento e le aziende che utilizzano software Bitcoin, iniziassero semplicemente a rifiutare qualsiasi blocco che non segnalasse il supporto a SegWit a partire dal 1° agosto 2017.
La logica era semplice: i miner producono blocchi, ma questi hanno valore solo se la rete li accetta. Se una maggioranza economica sufficiente avesse gestito nodi BIP 148, i miner avrebbero dovuto attivare SegWit o vedere i propri blocchi diventare orfani. Il rischio era altrettanto chiaro: se l'adozione fosse stata insufficiente, si sarebbe verificata una divisione della catena, con due versioni incompatibili di Bitcoin in esecuzione in parallelo.
La campagna UASF è stata un movimento popolare e molto vivace. Sono comparsi i badge della conferenza. Le discussioni su Twitter si sono intensificate. La frase "gestisci il tuo nodo" ha assunto un nuovo significato di urgenza.
L'accordo di New York e Bitcoin Cash
Di fronte alla scadenza dell'UASF, nel maggio 2017 oltre 50 importanti aziende del settore Bitcoin si sono riunite a New York e hanno firmato quello che è poi stato denominato l'Accordo di New York. Hanno concordato di attivare SegWit, ma anche di procedere successivamente con un hard fork per raddoppiare la dimensione dei blocchi a 2 MB (questo è diventato noto come SegWit2x).
Il compromesso non ha soddisfatto pienamente nessuna delle due parti. Gli sviluppatori contrari all'aumento della dimensione dei blocchi hanno visto in SegWit2x un hard fork "di nascosto" che non avevano approvato. I miner e le aziende che volevano blocchi più grandi continuavano a non ottenere ciò che desideravano inizialmente.
Il 1° agosto 2017, una fazione che auspicava un semplice aumento della dimensione dei blocchi, senza SegWit, ha effettuato un fork di Bitcoin per creare Bitcoin Cash (BCH), con un limite iniziale di 8 MB per blocco. SegWit è stato attivato su Bitcoin il 24 agosto 2017. L'hard fork SegWit2x è stato abbandonato nel novembre 2017 dopo che i suoi organizzatori hanno concluso di non avere un consenso sufficiente.
Cosa è stato stabilito
Il risultato è stato significativo ben al di là dei dettagli tecnici. L'UASF aveva funzionato: erano stati i nodi economici, e non i miner, a determinare quali regole di consenso applicare. Questo episodio viene ora regolarmente citato come prova del fatto che la governance di Bitcoin spetta in ultima analisi a chi gestisce e utilizza il software, e non a chi produce i blocchi. Il 1° agosto è considerato da una parte della comunità come il "Giorno dell'Indipendenza" di Bitcoin.
Cosa ha reso possibile SegWit
La rete Lightning
Il Lightning Network è stato progettato prima che SegWit esistesse. I suoi ideatori sapevano che non avrebbe potuto essere implementato in modo sicuro finché non fosse stato risolto il problema della malleabilità delle transazioni, poiché i canali di pagamento si basano su catene di transazioni non confermate che si riferiscono l'una all'altra tramite il TXID. La garanzia di TXID fisso offerta da SegWit ha reso sicuri tali canali.
Il Lightning Network è stato lanciato sulla mainnet di Bitcoin all'inizio del 2018, circa sei mesi dopo l'attivazione di SegWit. Entro il primo trimestre del 2025, aveva già elaborato oltre 100 milioni di transazioni. Senza SegWit, nessuna di queste infrastrutture esisterebbe.
Taproot e il controllo delle versioni degli script
SegWit ha introdotto il controllo delle versioni dello script nel formato delle transazioni di Bitcoin. Il programma witness inizia con un byte di versione: SegWit V0 copre P2WPKH e P2WSH. Qualsiasi aggiornamento futuro che definisca un nuovo numero di versione avrà le proprie regole senza entrare in conflitto con quelle esistenti e senza richiedere un'altra controversa battaglia per l'aggiornamento.
SegWit V1 è Taproot, attivato nel novembre 2021. Ha introdotto le firme Schnorr, il framework MAST (Merkelized Abstract Syntax Trees) per condizioni di spesa complesse e miglioramenti alla privacy che rendono i portafogli multisig indistinguibili dalle transazioni single-sig sulla blockchain. Ogni funzionalità tecnica introdotta da Taproot si basava sull'architettura di versioning creata da SegWit.
Numeri ordinali e iscrizioni
La stessa struttura dei dati di witness introdotta da SegWit e ampliata da Taproot ha reso tecnicamente possibile incorporare dati arbitrari, immagini, testo e codice direttamente nelle transazioni Bitcoin. Questo è il meccanismo alla base del protocollo Ordinals e delle iscrizioni Bitcoin, che ha determinato un'impennata nell'utilizzo dei dati on-chain e ha portato l'adozione di Taproot a circa il 42% delle transazioni nel 2024. Con il calo dell'attività di iscrizione, l'utilizzo di Taproot si è stabilizzato intorno al 20% delle transazioni alla fine del 2025, mentre SegWit V0 rimane il formato dominante con circa l'85%.
SegWit nel contesto: la cronologia degli aggiornamenti di Bitcoin
Adozioni in corso
L'adozione di SegWit è cresciuta costantemente dopo l'attivazione, raggiungendo il 30% delle transazioni nei primi mesi, per poi superare la soglia del 50% nei due anni successivi, man mano che i portafogli e le piattaforme di scambio aggiornavano il proprio software.
Nel 2026, circa l'85% delle transazioni Bitcoin utilizza SegWit (fonte: Spark.money Bitcoin Network Statistics, CoinGecko). Il restante 15% è costituito da transazioni legacy provenienti da portafogli e servizi che non hanno effettuato l'aggiornamento. L'adozione di Taproot (P2TR, SegWit V1) ha raggiunto il picco di circa il 42% delle transazioni nel 2024, trainata in gran parte dall'attività di iscrizione degli Ordinals, prima di attestarsi intorno al 20% verso la fine del 2025 con il calo del volume delle iscrizioni.
La curva di adozione rispecchia quanto accaduto con lo stesso SegWit: i nuovi formati di indirizzo impiegano da uno a tre anni per affermarsi su larga scala, man mano che i portafogli hardware, le piattaforme di scambio e i gestori di pagamenti aggiornano i propri software. Il supporto a Taproot continua ad espandersi tra le diverse implementazioni dei portafogli.
SegWit vs. Legacy: sintesi delle differenze
1...bc1q... (nativo) oppure 3... (annidato)1...bc1q... (nativo) oppure 3... (annidato)Conclusione
SegWit è l'aggiornamento del protocollo che ha separato i dati delle firme di Bitcoin dai dati delle transazioni, ha risolto una falla di sicurezza presente dal 2009, ha ridotto le commissioni di transazione di circa un terzo e ha gettato le basi architetturali per il Lightning Network, Taproot e tutto ciò che è stato sviluppato su di essi da allora.
A partire dal 2026, è lo standard di transazione su Bitcoin, che gestisce la stragrande maggioranza dell'attività on-chain. I formati di indirizzo che ha introdotto, in particolare il SegWit nativo (bc1q), sono quelli che la maggior parte degli utenti dovrebbe utilizzare oggi come impostazione predefinita. La battaglia politica che ha circondato la sua attivazione rimane uno dei capitoli più istruttivi nella storia della governance di Bitcoin: una dimostrazione del fatto che in una rete decentralizzata, il consenso non è qualcosa che i miner concedono, ma qualcosa che gli utenti affermano.
