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 Testimone isolato, è un aggiornamento del protocollo Bitcoin attivato nell'agosto 2017 che sposta i dati della firma digitale fuori dalla struttura principale della transazione e li inserisce in un campo separato denominato "witness". Questo singolo cambiamento architetturale 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, quali sono le implicazioni dei diversi tipi di indirizzo sulle commissioni e la controversa battaglia politica che ha rischiato di lacerare la rete Bitcoin prima ancora che SegWit venisse attivato.
Gestisci i tuoi Bitcoin con il App Bitcoin.com Wallet.
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 denominata “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, il che garantisce 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 riduzione delle commissioni di circa il 38% rispetto agli indirizzi tradizionali.
- La garanzia di TXID fisso offerta da SegWit era il presupposto tecnico per la realizzazione 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, ovvero 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 e le memorizza in una struttura separata denominata “witness”. Ciò riduce le dimensioni di ogni transazione, consente di inserire un maggior numero di transazioni in ogni blocco ed elimina una vulnerabilità che aveva reso impossibile la creazione sicura di 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 alla domanda “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 in occasione della 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 delle transazioni; 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, ovvero 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ò lasciava 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 da generare un TXID diverso. I fondi venivano comunque inviati all’indirizzo corretto e la transazione veniva comunque eseguita, ma l’identificatore era cambiato.
Per un semplice pagamento, la cosa non sembra poi così grave. Per i protocolli che concatenano tra loro più transazioni non confermate, invece, è fatale. Il Lightning Network, che funziona creando una serie di impegni di pagamento off-chain che fanno riferimento agli ID delle transazioni precedenti, non può funzionare in modo sicuro se uno qualsiasi di questi ID può cambiare prima della conferma. Un TXID mutabile comporta la rottura della catena e i fondi possono rimanere bloccati o essere rubati.
La malleabilità delle transazioni ha causato danni concreti prima che venisse risolta. La piattaforma di scambio Mt. Gox l'ha indicata come uno dei fattori che hanno contribuito al suo crollo nel 2014, anche se gli storici discutono su fino a che punto essa sia stata la causa principale o piuttosto un pretesto per nascondere una gestione ancora più scorretta.
SegWit ha risolto questo problema eliminando completamente le firme dal calcolo del TXID. L'identificatore viene ora calcolato esclusivamente sulla base dei campi di base 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, l’arretrato delle transazioni raggiungeva 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 marcatore (0x00) e un flag (0x01), indicano ai nodi compatibili con SegWit che seguono i dati del witness. I nodi precedenti all’introduzione di SegWit vedono semplicemente uno ScriptSig vuoto ed elaborano la transazione come valida secondo la vecchia interpretazione “chiunque può spendere”, mantenendo 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 dettaglio fondamentale 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 testimonianza costa solo 1 unità di peso
Poiché le firme sono di grandi dimensioni 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 di fatto la dimensione effettiva del blocco a circa 1,7-2 MB senza modificare la regola dell’1 MB applicata dai nodi più vecchi. Per un blocco teoricamente interamente SegWit, il limite massimo è di 4 MB, anche se ciò non si verifica mai nella pratica poiché ogni blocco contiene anche dati non relativi al 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 wallet 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
| Tipo di indirizzo | Prefisso | Codifica | Dimensioni tipiche del Tx (1 ingresso, 2 uscite) | Risparmio sulle commissioni vs sistema tradizionale | Supporto per portafogli |
|---|---|---|---|---|---|
| Legacy (P2PKH) | 1... | Base58 | ~226 vbyte | Valori di riferimento | Universale |
| SegWit annidato (P2SH-P2WPKH) | 3... | Base58 | ~167 vbyte | ~26% | Molto ampio |
| SegWit nativo (P2WPKH) | bc1q... 42 caratteri | Bech32 | ~141 vbyte | circa il 38% | Tutti i portafogli moderni |
| Multisig nativo SegWit (P2WSH) | bc1q... 62 caratteri | Bech32 | Varia | ~32%+ | Tutti i portafogli moderni |
| Taproot (P2TR) | bc1p... 62 caratteri | Bech32m | ~154 vbyte | circa il 32% | I portafogli più moderni |
Dati relativi all'entità delle transazioni: Spark.money: Riferimento sulle dimensioni delle transazioni in 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 il peso massimo. Nessun risparmio sulle commissioni. È ancora supportato universalmente, il che rappresenta l’unico motivo per utilizzarlo oggi, nel caso in cui si abbia a che fare con software molto datato che non è in grado di gestire altri formati.
SegWit annidato (P2SH-P2WPKH, prefisso 3...) racchiude uno script SegWit all’interno di una busta P2SH di vecchia generazione. Quando SegWit è stato attivato nel 2017, non tutti i portafogli e le piattaforme di scambio 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 tra loro (nessuna O maiuscola, zero, I maiuscola o l minuscola). Una transazione P2WPKH standard con 1 input e 2 output occupa circa 141 vbyte, circa il 38% in meno rispetto alla transazione legacy equivalente. A partire dal 2026, tutti i portafogli e gli exchange attivi la supportano.
Multisig nativo SegWit (P2WSH, prefisso bc1q..., 62 caratteri) è la variante script-hash, utilizzata per i portafogli multisig e per condizioni di spesa complesse. L'indirizzo più lungo riflette un hash SHA-256 da 32 byte anziché l'hash da 20 byte utilizzato da P2WPKH. Se si utilizza una configurazione multisig 2 su 3, P2WSH è il metodo nativo di SegWit per realizzarla.
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 un'unica firma, rendendo le transazioni multisig indistinguibili da quelle single-sig sulla blockchain. Offre le commissioni più basse per le transazioni 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 delle persone: utilizzate SegWit nativo (bc1q). È supportato praticamente da tutti i wallet 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 wallet, consultate il Guida allo sviluppo del portafoglio Bitcoin Core.).
Se il tuo portafoglio supporta Taproot (bc1p) e stai effettuando transazioni con firma singola con destinatari i cui portafogli lo supportano, ciò garantisce commissioni leggermente inferiori e una maggiore privacy.
Il SegWit annidato (3...) è una soluzione di ripiego per motivi di compatibilità. Va bene, ma non c'è più motivo di impostarlo come opzione predefinita.
La guerra sulla dimensione dei blocchi: perché SegWit è stato così controverso
Gli aspetti tecnici di SegWit erano chiari. 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ù controverse della sua storia. In sostanza, la questione era semplice: in che modo una rete decentralizzata dovrebbe aggiornare le proprie regole quando diverse fazioni 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 società 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 vantaggio significativo in termini di efficienza. SegWit era strutturalmente incompatibile con l’ASICBoost nascosto. Bloccare SegWit serviva a proteggere 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 da parte dei miner, il BIP 148 proponeva che i nodi economici, ovvero gli exchange, i gestori di pagamenti 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 oppure 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 che avrebbero funzionato in parallelo.
La campagna UASF è stata un movimento dal basso e molto vivace. Sono comparsi i badge della conferenza. Le discussioni su Twitter si sono intensificate. La frase “gestisci il tuo nodo” ha assunto una nuova 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 è diventato noto come 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 auspicavano 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 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 dimostrazione del fatto che la governance di Bitcoin spetta in ultima analisi a chi gestisce e utilizza il software, 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
Il Lightning Network
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 un 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 elaborato oltre 100 milioni di transazioni. Senza SegWit, nessuna di quelle 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 identici alle 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 su 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à relativa alle iscrizioni, l’utilizzo di Taproot si è stabilizzato intorno al 20% delle transazioni verso la fine del 2025, mentre SegWit V0 rimane il formato dominante con circa l’85%.
SegWit nel contesto: la cronologia degli aggiornamenti di Bitcoin
| Anno | Evento |
|---|---|
| 2015 | Pieter Wuille presenta il concetto di SegWit alla conferenza Scaling Bitcoin |
| 2016 | Pubblicato ufficialmente il BIP 141; il consenso dei miner si attesta al di sotto della soglia del 95% |
| Marzo 2017 | BIP 148 (UASF) pubblicato da Shaolinfry |
| Maggio 2017 | Accordo di New York firmato da oltre 50 aziende |
| 1° agosto 2017 | Bitcoin Cash si è separato da Bitcoin |
| 24 agosto 2017 | SegWit viene attivato su Bitcoin al blocco 481.824 |
| Novembre 2017 | Abbandonato l'hard fork di SegWit2x |
| Gennaio 2018 | Il Lightning Network viene lanciato sulla mainnet |
| Novembre 2021 | Taproot entra in funzione, basandosi sul sistema di versioning di SegWit |
| 2023-2024 | Gli ordinali e le iscrizioni sfruttano lo spazio testimone di SegWit/Taproot |
| 2026 | Circa l'85% delle transazioni in Bitcoin utilizza SegWit |
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.
A partire dal 2026, circa l’85% delle transazioni in 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, per poi stabilizzarsi 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 raggiungere l’adozione di massa, man mano che i portafogli hardware, le piattaforme di scambio e i gestori di pagamenti aggiornano il proprio software. Il supporto a Taproot continua ad espandersi nelle diverse implementazioni dei portafogli.
SegWit vs. Legacy: sintesi delle differenze
| Caratteristica | Versione precedente (pre-SegWit) | SegWit |
|---|---|---|
| Posizione della firma | All'interno di ScriptSig (corpo principale della transazione) | Campo testimone separato |
| Metrica relativa alla dimensione del blocco | Dimensione in byte (limite di 1 MB) | Unità di peso (limite di 4 milioni di WU) |
| Calcolo del TXID | Include i dati della firma | Esclude i dati relativi ai testimoni |
| Malleabilità delle transazioni | Possibile | Corretto |
| Dimensioni tipiche di un trasmettitore con 1 ingresso e 2 uscite | ~226 vbyte | ~141 vbyte (P2WPKH) |
| Risparmio sulle commissioni | Valori di riferimento | ~38% in meno (P2WPKH rispetto a P2PKH) |
| Supporto per Lightning Network | Non sicuro | Obbligatorio; abilita i canali di pagamento |
| Prefisso dell'indirizzo | 1... | bc1q... (nativo) oppure 3... (annidato) |
| Codifica | Base58 | Bech32 |
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 fin 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 accompagnato 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.
