Transazione serializzata

Tutto ciò che di una transazione appare amichevole, gli indirizzi, gli importi nella tua valuta locale, le etichette, è decorazione che aggiunge il tuo wallet. Ciò che viaggia davvero è un blob binario compatto, di norma da 200 a 250 byte per un pagamento semplice, ed è del tutto autosufficiente. Copia quel codice esadecimale da un computer offline a un qualsiasi computer online e il pagamento può essere trasmesso da lì.

Come funziona

La serializzazione è un ordine fisso senza nomi di campo, perciò i parser si affidano interamente alla posizione e ai prefissi di lunghezza.

Il blob si apre con la versione di quattro byte. Le transazioni Segregated Witness inseriscono poi due byte di flag, 0x00 e 0x01, che i parser più vecchi leggerebbero come una transazione con zero input e quindi rifiuterebbero, un espediente deliberato che ha permesso al nuovo formato di convivere con il vecchio. Segue il numero di input come intero compactSize, poi ogni input: 36 byte che indicano la moneta spesa, uno script di sblocco con prefisso di lunghezza e un numero di sequenza di quattro byte. Poi il numero di output, quindi ogni output come importo di otto byte in satoshi più uno script di blocco con prefisso di lunghezza. I dati witness, quando presenti, stanno verso la fine, e gli ultimi quattro byte sono sempre il locktime.

I numeri sono memorizzati in little endian, con il byte meno significativo per primo, ed è per questo che un importo di 100.000 satoshi compare nell'esadecimale come a0 86 01 00 00 00 00 00. Gli hash sono memorizzati nell'ordine interno dei byte, l'inverso di quello che ti mostra un explorer, così gli ID di transazione dentro un blob grezzo sembrano al contrario.

Da questa unica struttura derivano due hash. L'ID di transazione è un doppio SHA-256 calcolato sulla serializzazione senza il marker, il flag e il witness, ed è ciò che rende le firme immuni a una manomissione successiva. L'ID di transazione witness, definito nel BIP141, calcola l'hash dell'intero insieme, witness compreso, e i nodi lo usano per la contabilità dell'inoltro. Un pagamento SegWit nativo con un input e due output si serializza in circa 222 byte grezzi e conta come circa 141 byte virtuali, perché la parte witness è scontata.

Dove lo vedi

La forma grezza emerge appena esci da una singola app, il che per la maggior parte delle persone significa firmare offline o recuperare un pagamento.

I wallet hardware e le configurazioni air-gapped esportano una transazione completata come esadecimale o come codice QR che contiene gli stessi byte, e tu lo incolli nel modulo di trasmissione di un block explorer per inviarla. La riga di comando di Bitcoin Core la usa in entrambe le direzioni: createrawtransaction e signrawtransactionwithwallet producono esadecimale, decoderawtransaction riconverte l'esadecimale in JSON leggibile e sendrawtransaction la mette sulla rete. Le richieste al supporto spesso chiedono l'esadecimale grezzo invece dell'ID di transazione, perché l'esadecimale dimostra che cosa contiene la transazione invece di limitarsi a nominarla.

Una nota di sicurezza. Una transazione grezza firmata è informazione al portatore: chiunque abbia l'esadecimale può trasmetterla, e nulla in essa è riservato. Non incollarne una in un forum pubblico mentre chiedi aiuto, a meno che tu non accetti che il pagamento venga eseguito.

Transazione serializzata vs ID di transazione

La transazione serializzata è il documento; l'ID di transazione è il suo nome file. Una è qualche centinaio di byte in esadecimale, che su schermo possono arrivare a cinquecento caratteri, e l'altro è sempre esattamente di 64 caratteri esadecimali.

Le persone li confondono perché entrambi sembrano lunghe stringhe esadecimali. La prova sono la lunghezza e ciò che la stringa può fare. Una stringa di 64 caratteri può essere cercata su un explorer e nulla più. Una stringa più lunga può essere decodificata in campi e, se è firmata per intero, può essere trasmessa da chiunque la possieda, compreso uno sconosciuto a cui l'hai inviata.