Glossario / Protocollo e aggiornamenti
SegWit
Noto anche come Segregated Witness, BIP141, Witness segregato.
- Che cos'è SegWit?
- SegWit ha spostato i dati della firma fuori dalla parte di una transazione che il txid impegna, risolvendo la malleabilità delle transazioni e aumentando la capacità dei blocchi senza modificare il limite base di un megabyte.
Specificato nel BIP-141.
Il cambiamento è stato strutturale, non cosmetico. Le firme sono passate in una sezione witness che i nodi vecchi non scaricano mai, il che ha permesso di distribuire un aumento di capacità come soft fork, e ogni byte di witness costa un'unità di peso invece di quattro. Spendere da un indirizzo bc1q costa quindi circa la metà di quanto costa un input legacy.
Come funziona
Segregated Witness divide una transazione in due parti e ne calcola l'hash separatamente.
La parte base contiene la versione, gli input, gli output e il locktime. La parte witness contiene, per ogni input, la pila di elementi che lo autorizza, di norma una firma e una chiave pubblica. L'identificatore della transazione è calcolato solo sulla parte base, quindi nulla nel witness può cambiarlo. Un secondo identificatore, il wtxid, copre entrambe, e la radice di Merkle di tutti i wtxid di un blocco è impegnata dentro la transazione coinbase, così nemmeno i dati witness possono essere manomessi.
La capacità deriva da un cambiamento della contabilità, non del limite. Ogni byte fuori dal witness costa quattro unità di peso, ogni byte dentro ne costa una, e un blocco può contenere 4.000.000 unità di peso. I dati non witness non possono quindi ancora superare 1.000.000 byte, esattamente come prima, mentre le firme viaggiano nel budget rimasto. Un nodo precedente al 2017 che misura al vecchio modo vede un blocco valido e non solleva obiezioni, ed è proprio per questo che l'aggiornamento non ha richiesto un hard fork.
Il BIP-143 ha riscritto il modo in cui si firma un input witness, e il guadagno pratico è maggiore di quanto sembri. Il vecchio algoritmo di hash della firma ricalcolava l'hash di parti della transazione una volta per input, quindi firmare una transazione con molti input cresceva in modo quadratico. Il nuovo riutilizza hash precalcolati e, cosa decisiva, impegna l'importo speso. Prima, a un wallet hardware si poteva mentire su quanto valesse un input e indurlo ad autorizzare una commissione enorme.
SegWit ha anche numerato i suoi tipi di output. La versione witness 0 copre P2WPKH e P2WSH; la versione witness 1 è rimasta vuota e più tardi è stata occupata da Taproot. Ora si possono aggiungere nuovi tipi di output senza rimettere ogni volta in discussione il formato degli indirizzi.
Perché questo conta quando compri bitcoin
Tre cose nel tuo uso di bitcoin risalgono direttamente a questo aggiornamento.
La prima è quanto paghi per spostare bitcoin. Un input SegWit nativo occupa circa 68 vbyte contro circa 148 di uno legacy, quindi un wallet che spende tre input con una commissione di 20 sat/vB risparmia diverse migliaia di satoshi su una singola transazione. Quel risparmio arriva quando spendi, non quando ricevi, quindi conta il tipo di indirizzo che usa il tuo wallet, non quello da cui preleva il tuo exchange.
La seconda è quanto il tuo wallet hardware può dirti in sicurezza. Poiché il BIP-143 impegna l'importo dell'input, la commissione mostrata sullo schermo di un Trezor o di un Ledger deriva da dati che il dispositivo può verificare e non da dati che il computer collegato afferma. Questo ha chiuso un attacco reale, ed è per questo che firmare un input legacy richiede ancora che al dispositivo sia consegnata l'intera transazione precedente perché verifichi da sé l'importo.
La terza è Lightning, e quindi qualsiasi exchange costruito su di essa. Strike sposta valore su Lightning per impostazione predefinita, e i canali Lightning sono finanziati in output SegWit perché il protocollo non può funzionare senza un txid stabile. Senza SegWit niente canali, e nessun prodotto di regolamento istantaneo costruito su di essi.
Il bug di malleabilità che doveva sparire prima
La malleabilità delle transazioni sembra un caso limite ed è stata il singolo ostacolo più grande alla costruzione di qualsiasi cosa sopra bitcoin.
Una firma ECDSA ha più di una codifica valida. Prima di SegWit, un terzo che osservava la mempool poteva prendere una transazione non confermata, ricodificare una firma senza invalidarla e ritrasmetterla. I bitcoin andavano comunque nello stesso posto per lo stesso importo. Cambiava solo l'identificatore della transazione, e qualsiasi software che aveva registrato l'identificatore originale credeva ora che il pagamento fosse svanito. Mt. Gox ha pubblicamente attribuito alla malleabilità la sospensione dei prelievi a febbraio 2014, un'affermazione che altri sviluppatori all'epoca contestarono, ma il difetto di fondo era reale.
I canali di pagamento lo hanno reso fatale invece che fastidioso. Un canale funziona tenendo una transazione di rimborso firmata che spende un output di finanziamento identificato dal suo txid, prima ancora che quella transazione di finanziamento sia trasmessa. Se il txid cambia, il rimborso diventa impossibile da spendere, e una parte resta in grado di tenere in ostaggio il denaro dell'altra. Il documento del 2015 sulla Lightning Network di Joseph Poon e Thaddeus Dryja indicava nel proprio testo una correzione della malleabilità come prerequisito.
SegWit ha eliminato il problema alla radice togliendo le firme dalla preimmagine dell'identificatore. Ogni input che spende un output witness ha un txid che nessun terzo può alterare, e i protocolli dei canali hanno finalmente potuto essere costruiti come erano stati progettati.
SegWit vs dati witness
SegWit è l'aggiornamento; i dati witness sono la struttura che ha creato. Uno è un evento con una data, il 24 agosto 2017, e una specifica, il BIP-141. L'altro è un campo presente oggi nella maggior parte delle transazioni sulla rete, che porta firme e script e che ha una propria serializzazione e un proprio peso scontato. Dire che una transazione "usa SegWit" è un modo abbreviato di dire che spende input la cui autorizzazione vive in quel campo.
SegWit vs Taproot
Due soft fork, a quattro anni di distanza, entrambi sui witness. SegWit ha creato la struttura witness e definito i tipi di output di versione 0, quelli i cui indirizzi iniziano con bc1q. Taproot ha occupato la versione 1, ha aggiunto le firme Schnorr e ha cambiato il modo in cui si valutano gli script dentro un witness, producendo indirizzi che iniziano con bc1p. Taproot ha potuto essere distribuito a un costo così basso solo perché SegWit aveva già costruito lo schema di versionamento, ed è per questo che conviene leggere i due come un unico progetto realizzato per tappe.