Trasporto cifrato BIP-324

Due nodi che gestiscono entrambi BIP-324 eseguono uno scambio di chiavi effimere prima che venga inviato qualsiasi messaggio Bitcoin, poi avvolgono ogni messaggio in ChaCha20Poly1305. La specifica è stata contrassegnata come definitiva il 10 luglio 2024, e un nodo annuncia il supporto con il flag di servizio NODE_P2P_V2, il bit 11. Nulla cambia nei tuoi bitcoin: ciò che cambia è che un osservatore passivo non può più leggere le transazioni che il tuo nodo trasmette.

Come funziona

BIP-324 sostituisce i byte magici fissi che un tempo aprivano una connessione bitcoin con un flusso che non ha alcuna forma riconoscibile.

Il lato che avvia la connessione genera una chiave secp256k1 usa e getta e invia la codifica ElligatorSwift di 64 byte della propria chiave pubblica. Quella codifica è il trucco: una chiave pubblica ordinaria è identificabile come punto della curva, mentre ogni stringa di 512 bit è una codifica ElligatorSwift valida, quindi i byte iniziali sono statisticamente solo rumore. Poi ciascun lato può aggiungere fino a 4095 byte di riempimento arbitrario, chiamato garbage, così una connessione non deve iniziare esattamente con 64 byte. Entrambe le estremità eseguono ECDH X-only e passano il risultato attraverso HKDF-SHA256 per ricavare quattro chiavi di cifratura, due terminatori garbage da 16 byte e un ID di sessione.

Quei byte iniziali sono l'unica parte dello scambio inviata in chiaro. Dopo i terminatori, tutto ciò che passa sulla rete è costituito da pacchetti. Un pacchetto è un campo di lunghezza cifrato di 3 byte seguito da un testo cifrato ChaCha20Poly1305 che copre un'intestazione di 1 byte e il contenuto, con un costo di 20 byte più il payload. Il bit più alto di quell'intestazione è il bit ignore, e un pacchetto che lo porta è un'esca: il destinatario verifica che si decifri e poi lo scarta, ed è così che un nodo può riempire il proprio traffico per mascherare il momento in cui è partito un messaggio reale. Le chiavi avanzano a cricchetto ogni 224 pacchetti, un intervallo scelto perché un collegamento quasi inattivo che non invia altro che ping ogni 20 minuti rinnovi le chiavi all'incirca ogni 3,11 giorni, e quel cricchetto è ciò che dà a una sessione la segretezza in avanti.

Il progetto si ferma deliberatamente prima di dimostrare chi è dall'altra parte. Non ci sono certificati né identità, quindi un intermediario determinato può ancora inserirsi tra due nodi. Ciò che non può fare è inserirsi a buon mercato o in modo invisibile: l'ID di sessione deriva dallo scambio di chiavi, e due operatori che si leggono ad alta voce il proprio ID di sessione vedranno valori diversi ogni volta che qualcuno si trova in mezzo.

Dove lo vedi

BIP-324 non lascia nulla sulla blockchain, quindi l'unico posto in cui compare è tra due nodi in funzione.

Il supporto è annunciato nel gossip degli indirizzi tramite il flag NODE_P2P_V2 che i peer apprendono dai messaggi addr e addrv2. Quei flag passano attraverso relay non attendibili e vengono combinati con un OR logico, quindi un annuncio falso è possibile, e il BIP incoraggia un client v2 che viene disconnesso subito a riprovare con lo stesso peer tramite v1. Nella direzione opposta, un nodo v2 continua ad accettare di proposito connessioni v1 in entrata, per evitare che la rete si divida in due metà che non riescono a raggiungersi.

Il secondo effetto visibile sono messaggi più corti. La versione 1 spendeva 12 byte ASCII per ogni nome di comando; la versione 2 assegna ID di un byte ai 28 tipi di messaggio definiti finora, quindi inv è il singolo byte 14 e getblocktxn è 10, e qualsiasi messaggio che usa un ID corto costa 3 byte in meno della sua forma v1. Ciò che non ha un ID assegnato ricade su una codifica di 13 byte, un byte zero seguito dal vecchio nome ASCII, quindi nulla va perso.

La specifica ha lo stato Deployed, include vettori di test e un'implementazione di riferimento in Python ingenua pensata solo come dimostrazione, ed è ancora in fase di modifica: la revisione 1.0.2 del 30 gennaio 2026 ha aggiunto una tabella degli ID dei tipi di messaggio in un file ausiliario, così altri BIP possono rivendicare ID senza modificare il documento principale. L'intestazione riporta anche che BIP-324 sostituisce BIP-151.