Intestazione del messaggio

Niente nel protocollo peer-to-peer descrive se stesso, quindi la busta deve farlo. I suoi quattro campi non cambiano mai dimensione né ordine, permettendo a un nodo di leggere esattamente 24 byte, sapere quanto altro sta per arrivare e chiudere la connessione con chiunque dichiari più dei 4.000.000 byte che Bitcoin Core accetta. Non ne vedrai mai una, ma un'intestazione malformata è il motivo per cui a volte una connessione con un peer sparisce senza spiegazione.

Come funziona

I quattro campi dell'intestazione si leggono in un ordine fisso, e ognuno condiziona ciò che accade dopo.

I byte da 0 a 3 contengono la stringa di avvio che identifica la rete. I byte da 4 a 15 contengono il comando: un nome ASCII in minuscolo riempito con byte nulli fino a dodici caratteri, ed è per questo che ogni tipo di messaggio in bitcoin ha un nome breve e che cmpctblock, con dieci caratteri, resta vicino al limite. I byte da 16 a 19 contengono la lunghezza del payload come intero senza segno in little-endian. I byte da 20 a 23 contengono un checksum, i primi quattro byte di un doppio SHA-256 calcolato sul payload.

Mettere la lunghezza prima del payload è la vera misura di sicurezza del progetto. Un nodo che ha consumato 24 byte sa già se il mittente dichiara qualcosa di assurdo, e Bitcoin Core rifiuta qualsiasi cosa oltre i 4.000.000 byte e si disconnette, senza allocare un buffer né attendere dati che potrebbero non arrivare mai. Con la lunghezza dopo il corpo, ci si affida al fatto che il mittente si fermi.

Il checksum merita meno rispetto di quanto di solito riceve. Quattro byte di hash intercettano un bit alterato su un collegamento difettoso, e non servono a nulla contro un peer che mente, dato che un mittente ostile calcola semplicemente il checksum su ciò che ha scelto di inviare. In bitcoin l'integrità deriva dalla validazione del contenuto rispetto alle regole di consenso, mai da questo campo.

Nel software più recente l'intera struttura è opzionale. Il trasporto della versione 2 di BIP324 cifra la connessione e sostituisce la busta in chiaro con una lunghezza offuscata che delimita ogni messaggio, più un identificatore corto di un byte per i tipi di messaggio più comuni, così un osservatore passivo non può più leggere i nomi dei comandi che passano sulla rete. Bitcoin Core lo ha introdotto come impostazione opzionale nella versione 26.0 e lo ha attivato per impostazione predefinita in una versione successiva.

Dove lo vedi

Le intestazioni dei messaggi compaiono nelle catture dei pacchetti e nella diagnostica del nodo stesso.

Esegui Bitcoin Core con -debug=net e il log registra i tipi e le dimensioni dei messaggi per ogni peer, che è il modo pratico per osservare cosa sta facendo davvero una connessione. Le righe che riportano PROCESSMESSAGE: INVALID MESSAGESTART indicano che un peer ha inviato byte che non iniziavano con la stringa di avvio di questa rete, cosa quasi sempre dovuta a qualcosa configurato male dall'altra parte e non a un attacco. Il dissettore bitcoin di Wireshark analizza gli stessi 24 byte per etichettare ogni frame.

Intestazione del messaggio vs intestazione del blocco

Un'intestazione del messaggio è l'imballaggio del trasporto; un'intestazione del blocco è un dato di consenso, e non condividono altro che la parola. L'intestazione del messaggio è di 24 byte, esiste solo per la durata di una consegna e viene scartata appena il payload è stato letto. L'intestazione del blocco è di 80 byte, contiene la versione, l'hash del blocco precedente, la radice di Merkle, la marca temporale, l'obiettivo di difficoltà e il nonce, e viene sottoposta a hash per produrre la proof of work che identifica quel blocco in modo permanente. Una è l'etichetta con l'indirizzo su un pacco; l'altra è ciò che c'è dentro.