Numero di versione della transazione

Solo tre valori hanno mai significato qualcosa. Il campo non è una versione software, non è una versione di protocollo e non è un indizio sui tipi di indirizzo contenuti nella transazione, che è gran parte di ciò che si suppone quando lo si vede per la prima volta. Il consenso è in larga misura indifferente al campo, mentre la policy di relay non lo è, e questa differenza è tutta la storia del campo.

Come funziona

La versione occupa i byte da 1 a 4 della forma serializzata, prima del conteggio degli input, e Bitcoin Core la legge come un intero con segno di 32 bit.

La versione 1 è quella originale, usata da tutte le transazioni nei primi anni della catena. La versione 2 esiste perché il BIP68 aveva bisogno di un modo per reinterpretare i numeri di sequenza come timelock relativi senza invalidare le transazioni più vecchie, così ha associato il nuovo significato a un incremento di versione. Dal blocco 419.328, a luglio 2016, i numeri di sequenza di una transazione che dichiara la versione 2 vengono controllati come periodi di attesa, mentre quelli di una che dichiara la versione 1 no. I wallet moderni impostano la versione 2 per impostazione predefinita, che usino o meno i timelock, ed è per questo che quasi tutto ciò che consulti su un explorer indica 2.

La versione 3 è arrivata con Bitcoin Core 28.0 a ottobre 2024, con il nome di topology restricted transactions, o TRUC. Dichiarare la versione 3 significa optare per un trattamento più rigoroso: la transazione è sempre considerata sostituibile, può avere al massimo una transazione madre non confermata e una figlia non confermata, la figlia è limitata a 1.000 byte virtuali e la transazione stessa a 10.000. Questi limiti sembrano un peggioramento finché non subisci il pinning, cioè quando una controparte aggancia un discendente enorme ed economico alla tua transazione non confermata così che aumentare la commissione diventi insostenibile. Le implementazioni Lightning hanno adottato la versione 3 proprio per questo motivo.

Nessuna regola di consenso rifiuta una transazione perché ha la versione 7, o la versione 0. Le regole di standardness sì: Bitcoin Core non trasmette né mina versioni al di fuori dell'insieme accettato, quindi una versione insolita è una transazione che deve arrivare a un miner in qualche altro modo.

Dove lo vedi

Ogni block explorer stampa la versione vicino all'inizio della pagina dei dettagli di una transazione, e decoderawtransaction di Bitcoin Core la restituisce come primo campo.

Per chi compra o detiene bitcoin, è uno strumento diagnostico più che una decisione. Non la scegli mai tu, la sceglie il tuo wallet. Il suo valore pratico sta nel leggere software sconosciuto: un wallet che produce ancora transazioni di versione 1 in un mondo di timelock relativi è vecchio, e un pagamento che dichiara la versione 3 quasi certamente è uscito dalla macchina dei canali di un nodo Lightning e non da una persona che ha premuto invio.

Numero di versione della transazione vs numero di versione del blocco

Transazioni e blocchi hanno entrambi un campo versione di quattro byte, e non hanno nulla a che fare l'uno con l'altro.

La versione del blocco segue gli aggiornamenti del consenso. I blocchi di versione 2 sono diventati obbligatori al blocco 227.931, a marzo 2013, quando il BIP34 ha richiesto l'altezza del blocco nell'input coinbase, la versione 3 ha imposto la codifica DER rigorosa delle firme con il BIP66, e la versione 4 è arrivata con il deployment di CHECKLOCKTIMEVERIFY. Dal 2015 in poi il campo è stato riutilizzato ancora come insieme di bit di segnalazione con il BIP9, così i miner potevano votare un soft fork cambiando uno dei suoi bit. La versione di una transazione non fa nulla di tutto ciò. Non segnala mai, non aumenta a ogni aggiornamento e si applica a una singola transazione, non all'insieme di regole dell'intera rete.