MSG_WITNESS_TX

Se richiedi una transazione tramite il suo txid con MSG_WITNESS_TX, ricevi indietro la versione con le firme allegate. Bitcoin Core 0.21.0, pubblicato il 14 gennaio 2021, ha aggiunto la trasmissione per wtxid e ha in gran parte sostituito questa richiesta con MSG_WTX, che richiede invece tramite l'hash del witness. Per chi invia bitcoin, il vantaggio è che una firma modificata non fa più sparire un pagamento dalla trasmissione.

Come funziona

Ogni transazione segwit ha due identità, e MSG_WITNESS_TX esiste perché a un peer va detto quale delle due gli si chiede di soddisfare.

Il txid è il doppio SHA-256 della transazione senza il suo witness: versione, input, output, locktime. Il wtxid è lo stesso hash calcolato sulla serializzazione completa, byte marker e byte flag e stack del witness inclusi. Per una transazione senza alcun witness i due sono uguali. Per la transazione coinbase il BIP141 definisce il wtxid come 32 byte di zero, un caso speciale che esiste perché la radice di merkle del witness abbia qualcosa di ben definito a cui appendersi.

Il codice della richiesta è 0x40000001: il tipo di transazione 1 con in più il flag del witness 0x40000000. Se invii un getdata con il solo tipo 1, il peer risponde con i byte privati del witness, che bastano per vedere dove sono finiti i fondi e sono inutili per verificare se la spesa era autorizzata.

È questa separazione ad aver posto fine al vecchio problema della malleabilità. Prima di segwit, un terzo poteva ricodificare una firma, cambiare il txid e lasciare il mittente in attesa di una transazione che con quel nome non esisteva più. Spostare le firme fuori dal txid ha chiuso quella porta, e chiuderla è ciò che ha reso affidabili le transazioni pre-firmate dei canali Lightning.

Il BIP339 ha poi portato la logica un passo più avanti. I peer che inviano un messaggio wtxidrelay prima di verack annunciano le transazioni tramite wtxid usando il tipo di inventario 5, e Bitcoin Core lo fa da 0.21.0. Il guadagno è nella cache delle transazioni rifiutate: un nodo che ha rifiutato un witness malformato non rifiuta più una copia onesta della stessa transazione, perché le due hanno wtxid diversi. MSG_WITNESS_TX sopravvive per i peer che non hanno mai negoziato la trasmissione per wtxid, il che in pratica significa software precedente a quella versione.

Dove lo vedi

Il posto più chiaro per vedere txid e wtxid affiancati è l'output delle chiamate RPC per le transazioni di Bitcoin Core stesso.

Chiama getrawtransaction con output dettagliato su qualsiasi spesa segwit e ottieni un campo txid e un campo hash. Sono diversi. L'hash è il wtxid, e la differenza è l'unica traccia visibile dei dati del witness in un oggetto JSON per il resto ordinario. Gli esploratori di blocchi indicizzano per txid, quindi è quel numero da incollare nella casella di ricerca quando controlli se il tuo prelievo è arrivato.

Sulla rete, getpeerinfo conta i messaggi per tipo, e le richieste di transazioni in quella ripartizione saranno miste su qualsiasi nodo ben connesso: MSG_WTX ai peer moderni, MSG_WITNESS_TX ai ritardatari.

Niente di tutto questo è qualcosa che un acquirente configura. Conta indirettamente. Quando un exchange ti dice che un prelievo è stato trasmesso e il tuo wallet non lo trova, la domanda utile è se il txid che ti è stato dato abbia mai raggiunto la mempool, non quale serializzazione si siano scambiati i peer.

MSG_WITNESS_TX vs MSG_TX

MSG_TX indica la stessa transazione e la restituisce con tutte le firme rimosse. È la forma che i nodi precedenti a segwit comprendevano, e circola ancora verso i peer che non hanno mai annunciato NODE_WITNESS. La distinzione non è estetica: un nodo che riceve la versione privata del witness può confermare la struttura della transazione ma non convalidarla, quindi non può inserirla in sicurezza in una mempool né ritrasmetterla come verificata. Bitcoin Core non invierà una transazione segwit a un peer che parla solo la forma più vecchia.