Glossario / Transazioni e commissioni
Maleabilità delle transazioni
Noto anche come Transaction malleability, Maleabilità.
- Che cos'è la maleabilità delle transazioni?
- La maleabilità delle transazioni è il difetto che permetteva a un terzo di cambiare l'id di una transazione senza cambiare dove andavano i soldi, ricodificando i dati della firma che conteneva.
Specificato nel BIP-66.
Il pagamento funzionava comunque; cambiava solo il suo nome. Bitcoin ha chiuso la falla per tappe tra il 2015 e il 2017, e SegWit ha completato il lavoro per gli input che tengono le firme nel witness. Gli input legacy restano maleabili, il che è un motivo in più per conservare i bitcoin su un indirizzo bc1.
Come funziona
L'id di una transazione è un hash dei byte della transazione, quindi alterare un qualsiasi byte produce un id diverso, e in un input legacy la firma è uno di quei byte.
Tre tipi di margine rendevano possibile un'alterazione senza rompere nulla.
Il primo è aritmetico. Una firma ECDSA è una coppia di numeri, r e s, e per ogni s valido esiste un secondo valore altrettanto valido: l'ordine della curva meno s. Chiunque osservi la rete può invertirlo e la verifica riesce comunque.
Il secondo è la codifica. Le firme erano avvolte in DER, e la biblioteca software su cui bitcoin si appoggiava accettava varianti sciatte: byte zero iniziali in eccesso, indicatori di lunghezza non canonici, un riempimento che nessun codificatore accurato avrebbe prodotto. Ogni variante dava un id diverso al calcolo dell'hash.
Il terzo è lo script di sblocco intorno alla firma. Aggiungere allo stack un elemento in più e innocuo lasciava identico il risultato dello script e diversi i byte serializzati.
Le correzioni sono arrivate uno strato alla volta. BIP66 ha reso la codifica DER rigorosa una regola di consenso all'altezza 363.725, il 4 luglio 2015, un'attivazione ricordata soprattutto perché diversi grandi pool stavano costruendo su intestazioni che non avevano validato e produssero quel pomeriggio un fork di sei blocchi. Bitcoin Core 0.11.1, pubblicato a ottobre 2015, ha reso i valori bassi di s una regola di politica di relay, documentata in seguito come BIP146. BIP62, un tentativo di elencare e vietare ogni fonte residua, fu abbandonato come impraticabile e porta ancora oggi lo stato Withdrawn. A chiudere la questione è stato SegWit, attivo all'altezza 481.824, il 24 agosto 2017: le firme si sono spostate nel witness, l'id si calcola senza il witness e per un input segwit semplicemente non resta nulla da mutare.
Dove lo vedi
La maleabilità non ha mai causato furti, ha causato errori contabili, e questa è ancora la forma del rischio.
A un custode che seguiva i prelievi tramite l'id che aveva diffuso si poteva mostrare una transazione confermata con un id diverso, fargli concludere che il proprio pagamento era fallito e fargli inviare di nuovo i bitcoin. Questo schema ha causato perdite reali negli exchange nel 2014, ed è il motivo per cui gli operatori seri riconciliano per indirizzo di output e importo, non solo per id.
Le transazioni concatenate sono state l'altra vittima. Una transazione figlia che spende una transazione madre non confermata la indica per id, quindi una madre mutata lascia la figlia definitivamente non spendibile. Qualsiasi protocollo che firmi un rimborso prima che la transazione di finanziamento sia trasmessa, che è esattamente ciò che fa l'apertura di un canale Lightning, non era sicuro da costruire finché gli id non sono diventati stabili.
Per chi compra e conserva, basta una sola abitudine. Un id non confermato non è un fatto. Può ancora cambiare per maleabilità sugli input legacy, e ora cambia di routine per un motivo non collegato, perché Bitcoin Core trasmette per impostazione predefinita il replace-by-fee completo e un mittente che aumenta la commissione pubblica un nuovo id. Attendi una conferma, poi cita l'id a chiunque te lo chieda.
Maleabilità delle transazioni vs doppia spesa
La maleabilità sposta l'etichetta; una doppia spesa sposta i soldi. In una transazione mutata gli stessi bitcoin arrivano allo stesso indirizzo per lo stesso importo, e solo il software che aveva memorizzato il vecchio id si accorge che è successo qualcosa. In una doppia spesa una transazione concorrente invia quei bitcoin altrove e una delle versioni finisce senza valore. Confondere le due cose insegna a diffidare dei pagamenti confermati, che è la lezione sbagliata: un id confermato non è mai stato maleabile, perché la maleabilità si è sempre applicata solo mentre una transazione era in attesa di conferma.