Messaggio P2P

Non esiste un server centrale da chiamare, quindi l'intera relazione di un nodo con la rete è questa conversazione. Bitcoin Core annuncia la versione del protocollo 70016, apre le sue connessioni sulla porta 8333 e l'intero vocabolario sta in una pagina. Il tuo prelievo arriva a un miner perché una macchina ha detto tx a un'altra, inoltrato qualche migliaio di volte in pochi secondi.

Come funziona

Ogni connessione si apre con un handshake e poi si assesta su un piccolo insieme di scambi ricorrenti.

La prima cosa che ciascuna delle due parti invia è version, che porta il numero di protocollo che parla, i suoi flag di servizio, l'ora corrente, l'indirizzo che ritiene abbia l'altro capo, un nonce casuale usato per rilevare un collegamento accidentale a se stesso, una stringa di user agent e l'altezza della migliore catena che conosce. Ciascuna parte risponde con verack. Finché entrambe non l'hanno fatto, non viene elaborato nient'altro.

Quel numero di protocollo è una scala di funzionalità, non un ornamento. L'annuncio diretto delle intestazioni richiede 70012, la negoziazione dei blocchi compatti richiede 70014, l'annuncio di un blocco compatto prima della validazione completa richiede 70015 e l'inoltro delle transazioni tramite identificatore di witness richiede 70016. Un nodo legge il numero del suo peer e rinuncia discretamente a offrire capacità che quel peer non può usare: è così che la rete si aggiorna senza un passaggio coordinato.

Raggruppato per scopo, il vocabolario è breve. Trovare peer: getaddr, addr e la variante addrv2 del BIP155, che può trasportare indirizzi Tor e I2P. Annunciare: inv e headers. Richiedere: getheaders, getdata, getblocks, mempool. Consegnare: tx, block, cmpctblock, blocktxn, notfound. Gestione ordinaria: ping, pong, sendheaders, sendcmpct, wtxidrelay e feefilter, l'ultimo dei quali dice a un peer di non preoccuparsi di inoltrare transazioni sotto una data commissione per unità di dimensione.

Due silenzi sono deliberati. I comandi non riconosciuti vengono ignorati anziché rifiutati, ed è ciò che consente a un nuovo tipo di messaggio di diffondersi gradualmente in una rete che nessuno può aggiornare tutta insieme. E non c'è modo per un peer di dirti perché ha scartato la tua transazione: il messaggio reject del BIP61 è stato disattivato per impostazione predefinita in Bitcoin Core 0.18.0 e l'opzione è stata rimossa del tutto in 0.20.0, perché le risposte non erano affidabili, erano facili da falsificare e venivano abitualmente prese per autorevoli.

Dove lo vedi

I messaggi P2P sono ciò che il tuo nodo fa tutto il giorno, e sono facili da osservare.

Avvia Bitcoin Core con -debug=net e il log nomina ogni messaggio quando arriva. La chiamata getpeerinfo riporta, per ogni connessione, i byte inviati e ricevuti suddivisi per tipo di messaggio, che è il modo più rapido per scoprire che un solo peer ti sta fornendo quasi tutto mentre gli altri restano inattivi. Trasmettere un pagamento da un wallet collegato al tuo nodo produce una piccola sequenza riconoscibile: un inv in uscita, un getdata in ritorno, un tx in uscita in risposta.

Messaggio P2P vs RPC

Bitcoin ha due interfacce e non sono intercambiabili. P2P è da nodo a nodo: senza autenticazione, senza cifratura a meno che entrambe le parti non negozino il trasporto v2, sulla porta 8333, con un vocabolario che nessun singolo partecipante può estendere. RPC è da programma a nodo: autenticato, locale per impostazione predefinita, sulla porta 8332, con un elenco di metodi che cambia a ogni rilascio. Un pagamento che crei passa attraverso entrambe: entra nel tuo nodo come chiamata RPC e ne esce come messaggio P2P, e solo la seconda metà riguarda qualcun altro.