Glossario / Riferimento per sviluppatori
Ordine dei byte RPC
- Che cos'è l'ordine dei byte RPC?
- L'ordine dei byte RPC è il modo invertito in cui il software bitcoin mostra gli hash di 32 byte, ed è la forma di ogni ID di transazione che copi da un wallet o da un block explorer.
La stringa di 64 caratteri che il tuo wallet chiama ID di transazione non segue l'ordine che quegli stessi byte hanno in qualsiasi altro contesto. Bitcoin Core conserva un hash in un tipo che lo stampa con il byte più significativo per primo, tutti gli explorer hanno copiato l'abitudine e ormai la convenzione è permanente. È innocua quando incolli un identificatore in un campo di ricerca ed è costosa quando lo incolli nel codice.
Come funziona
L'ordine dei byte RPC è una trasformazione di visualizzazione applicata all'uscita da un nodo, non un hash diverso.
Un digest esce da SHA-256 come 32 byte senza alcun verso di lettura intrinseco. Bitcoin Core lo conserva in un contenitore che tratta quei byte come un unico numero molto grande, e stampare un numero mette la parte più significativa a sinistra, il che inverte l'array. Ogni campo JSON che nomina un blocco o una transazione esce così: l'hash di getblockhash, il txid di getrawtransaction, il merkleroot di getblock, il previousblockhash che lega un blocco al suo blocco padre.
Una conseguenza si vede sulla prima pagina di ogni explorer. La proof of work produce digest che, in questo verso di stampa, iniziano con una lunga serie di zeri. Quegli zeri stanno all'estremo opposto dei byte grezzi. È più facile ragionare sui target di mining nella forma stampata, ed è in parte per questo che la convenzione è rimasta invece di essere corretta.
L'inversione riguarda solo gli hash. Le chiavi pubbliche, le firme, gli script e gli elementi witness sono tutti stampati nel loro ordine reale, quindi uno script ottenuto da decodescript si può confrontare direttamente con la transazione grezza, mentre un txid no. È proprio mescolando queste due regole che il codice funzionante di solito sbaglia.
Una singola risposta può perfino contenere entrambe le convenzioni insieme. Chiedi una transazione con output dettagliato e il campo txid è invertito, mentre il campo hex accanto è la serializzazione intatta che contiene lo stesso hash nel verso opposto.
Dove lo vedi
L'ordine dei byte RPC è l'unica forma di un hash che la maggior parte delle persone arriva a maneggiare.
È quello che un exchange mette in un'email di conferma di prelievo, quello che un block explorer si aspetta in un URL, quello che un operatore dell'assistenza ti chiede di inviare e quello che stampa bitcoin-cli. Chiedere a un nodo il primo blocco in assoluto con getblockhash 0 restituisce 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f, e incollando quella stringa in qualsiasi explorer si arriva al blocco minato il 3 gennaio 2009.
Il modo in cui si sbaglia è ristretto e coerente. Qualcuno calcola da sé un identificatore di transazione, applicando due volte SHA-256 alla serializzazione, confronta il risultato con un explorer e non trova alcuna somiglianza. Entrambe le stringhe sono gli stessi 32 byte e una delle due va invertita. La stessa correzione vale quando uno script estrae un txid da un input grezzo e lo cerca in una tabella di identificatori raccolti da un'API.
C'è un'abitudine di due secondi che vale la pena adottare. Se un hash che qualcuno ti ha inviato non porta da nessuna parte, provalo al contrario prima di concludere che la transazione non esista. I thread dell'assistenza sono pieni di hash copiati da dati grezzi invece che da un wallet, e sembrano del tutto validi finché non li inverti.