Protocollo · Upgrade
SegWit: Segregated Witness
SegWit (BIP141) è il più importante upgrade del protocollo Bitcoin prima di Taproot. Attivato nell'agosto 2017 dopo mesi di dibattito intenso, ha risolto la transaction malleability, aumentato la capacità effettiva dei blocchi e reso possibile Lightning Network. Nel 2025 oltre il 75% delle transazioni Bitcoin usa SegWit.
Il problema che SegWit ha risolto
Transaction malleability
Prima di SegWit, la firma di una transazione era parte dell'input e contribuiva al txid. Un attaccante poteva modificare la firma in modo da renderla ancora valida ma con txid diverso — prima della conferma.
Impatto: Lightning Network è impossibile senza txid stabili. I canali bi-direzionali richiedono transazioni che referenziano output non ancora confermati — se il txid cambia, il contratto si rompe.
Limite effettivo di 1MB per blocco
Il limite di 1MB era il collo di bottiglia principale per la scalabilità di Bitcoin. Ogni transazione occupava spazio proporzionale alla sua dimensione totale incluse le firme.
Impatto: Bassa throughput (~3-7 tps), fee alte durante congestione, conferme lente.
Come funziona SegWit
SegWit separa (segregates) i dati witness (le firme) dal resto della transazione. Le firme vengono spostate in una struttura separata — il 'witness data'.
Per la compatibilità con i vecchi nodi, SegWit è un soft fork: i vecchi nodi vedono le transazioni SegWit come valide (non le capiscono completamente, ma non le rifiutano).
I nuovi nodi vedono il witness data e lo verificano completamente. Il txid viene calcolato senza il witness — eliminando la malleability.
Viene introdotto il concetto di block weight: il limite non è più 1MB di dati, ma 4 milioni di weight units. I dati witness 'pesano' 1 WU per byte invece di 4 WU — effettivamente vengono scontati del 75%.
Risultato pratico: i blocchi SegWit possono contenere più transazioni. Un blocco con il 100% di tx SegWit raggiunge ~1.7-2MB di dati effettivi.
vByte: la nuova unità di misura
Formula: vByte = Weight / 4
Transazione base (non-SegWit): ~250 bytes = ~250 vBytes
P2WPKH (SegWit nativo): ~140 bytes fisici = ~68 vBytes → fee ~2.7x più basse
P2TR (Taproot): ~57-68 vBytes → fee ancora più basse rispetto a SegWit legacy
Quando un wallet calcola la fee per una transazione, usa i vByte — non i byte fisici. Usare indirizzi SegWit nativo (bc1q...) o Taproot (bc1p...) riduce significativamente le fee pagate.
Tipi di indirizzo SegWit
| Tipo | Prefisso | BIP | vByte tipici |
|---|---|---|---|
| Legacy (P2PKH) | 1... | BIP44 | ~148 vB input |
| Nested SegWit (P2SH-P2WPKH) | 3... | BIP49 | ~91 vB input |
| Native SegWit (P2WPKH) | bc1q... | BIP84 | ~68 vB input |
| Taproot (P2TR) | bc1p... | BIP86 | ~57 vB input |
Usare Native SegWit o Taproot riduce le fee del 30-60% rispetto a Legacy.
SegWit come prerequisito per Lightning Network
Lightning Network richiede commitment transactions — transazioni che non vengono trasmesse subito ma solo in caso di chiusura forzata di un canale.
Queste transazioni referenziano l'output del funding transaction (non ancora confermato al momento della costruzione). Se il txid cambia (malleability), la commitment tx è invalida.
SegWit rende il txid immutabile prima della conferma (perché le firme sono fuori dal txid hash). Questo è il motivo per cui Lightning non esisterebbe senza SegWit.
Anche Taproot ha migliorato Lightning: le chiavi Schnorr permettono MuSig2 per multisig cooperativi, rendendo i canali cooperativi indistinguibili da transazioni singole — migliorando privacy e efficienza.
Protocollo e upgrade ogni settimana
Il Report Fides Bitcoin analizza il protocollo Bitcoin, gli upgrade passati e quelli in sviluppo — in italiano, ogni lunedì.
Iscriviti gratis →