Su Delving Bitcoin si discute di un modo per far collegare direttamente tra loro i nodi Bitcoin domestici, quelli nascosti dietro il router di casa, con una tecnica chiamata TCP hole punching. Il tema è tornato nella newsletter Bitcoin Optech #430 del 6 novembre: secondo Optech, lo sviluppatore 0xB10C ha scritto che il lavoro su una specifica e su un’implementazione sperimentale in Bitcoin Core è ripreso. Non cambia nulla per chi usa Bitcoin: è una discussione sulla rete peer-to-peer, con diverse questioni ancora aperte.
Cosa è successo: il thread di 0xB10C torna attivo
Il thread «TCP hole punching for Bitcoin nodes behind home NATs?» su Delving Bitcoin conta 35 messaggi, tra l’11 maggio e il 3 novembre 2026. Lo ha aperto 0xB10C dopo una conversazione con willcl-ark, partendo da un problema: i nodi «raggiungibili» (reachable), cioè quelli che accettano connessioni in entrata, sono troppo pochi tra quelli che girano su connessioni domestiche.
Con Bitcoin Core v30.0, uscito il 10 ottobre 2025, l’opzione -natpmp è attiva per impostazione predefinita (PR #33004): un nodo dietro un router che supporta i protocolli PCP o NAT-PMP dovrebbe diventare raggiungibile. 0xB10C, nel suo post sul forum BNOC, ricorda che era questa la speranza. Per lui l’hole punching sarebbe un’aggiunta «best effort» (con risultato non garantito), non un sostituto di NAT-PMP né delle normali connessioni in entrata.
Perché i nodi di casa contano: i dati dopo Bitcoin Core 30
Dalla release di Bitcoin Core v30.0 i nodi raggiungibili su reti residenziali sono cresciuti di poco, secondo l’analisi di 0xB10C pubblicata su BNOC il 28 aprile 2026. L’analisi usa 36.310 snapshot della rete raccolti da Bitnodes tra il 10 luglio 2025 e il 27 aprile 2026. Con 58 ASN residenziali classificati a mano, l’aumento è di circa 100 nodi: per 0xB10C è lontano da un aumento netto come quello sperato da alcuni, e probabilmente non attribuibile a -natpmp ma in linea con un trend generale. Sono dati di aprile: il 19 ottobre 0xB10C ha scritto che avrebbe senso rifare i conteggi.
Estendendo il calcolo a tutti i sistemi autonomi (ASN, le reti dei provider) classificati come ISP, i dati di Bitnodes indicano +200-250 nodi residenziali, mentre quelli del KIT DSN indicano +150-200, riporta la stessa discussione. Nei sistemi classificati come hosting, cioè i data center, non c’è stata una variazione rilevante.
| Fonte dati | Perimetro | Variazione dei nodi residenziali dalla v30.0 |
|---|---|---|
| Bitnodes | 58 ASN residenziali, classificati a mano | circa +100 |
| Bitnodes | 1.410 ASN classificati come ISP | +200-250 |
| KIT DSN | 1.311 ASN classificati come ISP | +150-200 |
Fonte: forum BNOC, post di 0xB10C del 28-29 aprile 2026.
Nella discussione sono emersi due limiti. Il primo, indicato da deadmanoz, è che NAT-PMP non aiuta chi sta dietro un CGNAT (carrier-grade NAT, cioè un indirizzo pubblico condiviso dall’operatore tra più clienti). Il secondo, di mzumsande, è che molti nodi di casa non sono accesi 24 ore su 24, quindi i siti che elencano solo i nodi online potrebbero contarli poco.
Come funziona l’hole punching TCP
L’hole punching TCP permette a due computer dietro un NAT di collegarsi direttamente, senza che il traffico passi da un server, spiega 0xB10C nel primo messaggio del thread. Due nodi di casa, Alice e Bob, si collegano a un nodo raggiungibile, Charlie, che vede i loro indirizzi pubblici e glieli scambia. Poi Alice e Bob aprono nello stesso momento una connessione verso l’altro dalla stessa porta locale: i primi pacchetti (SYN) creano un «buco» nel NAT di ciascuno e le due connessioni si incontrano, un meccanismo descritto come apertura simultanea nella RFC 9293.
Non funziona con tutti i router. Secondo 0xB10C, che richiama la RFC 4787, con un mapping indipendente dalla destinazione (EIM) l’hole punching funziona, ed è un comportamento forse diffuso sui router domestici; con il mapping dipendente dall’indirizzo (ADM) è difficile; con il NAT simmetrico, tipico dei CGNAT, non funziona. 0xB10C aggiunge che TCP, essendo legato allo stato della connessione e ai tempi, è più delicato di UDP.
Le varianti sul tavolo: da un coordinatore a nessun coordinatore
Nel thread 0xB10C descrive almeno sei varianti, quattro riepilogate il 13 ottobre, una quinta indicata il 14 ottobre e una sesta proposta il 16 ottobre. Le varianti si distinguono soprattutto per chi fa da intermediario, o se non ce n’è nessuno.
| Variante | Come funziona |
|---|---|
| 1. Nodo coordinatore | A annuncia «trovami tramite C»; C manda a entrambi il segnale di avvio. La rete può ricavare che A e C erano collegati. |
| 2. Servizio Tor del nodo | A gestisce un servizio onion dedicato: B lo contatta via Tor, la connessione bucata passa poi in chiaro. Serve Tor da entrambi i lati. |
| 3. Pool di abbinamento | Il coordinatore accoppia da solo due nodi del pool: i nodi non scelgono con chi collegarsi. |
| 4. Passaggio al posto dell’espulsione | Un nodo con gli slot in entrata pieni, prima di scollegare un peer, lo presenta a un altro suo peer. |
| 5. Comando manuale | Un comando RPC per bucare il NAT con qualcuno che si conosce, coordinandosi per telefono, Signal o nostr. |
| 6. Senza coordinatore | Ogni nodo annuncia IP, porta e una chiave pubblica temporanea in un nuovo tipo di indirizzo addrv2; i tempi dipendono dai nuovi blocchi. |
Fonte: messaggi di 0xB10C nel thread su Delving Bitcoin, 13, 14 e 16 ottobre 2026.
Nella variante 6 due nodi ricavano lo stesso segreto condiviso e, a ogni nuovo blocco, calcolano un hash dal segreto e dall’hash del blocco per scegliere i candidati con cui provare. L’hash del blocco serve a evitare che un attaccante «macini» chiavi per diventare sempre il primo candidato. 0xB10C scrive che, nei test, qualche secondo di scarto tra gli orologi non ha contato.
Le obiezioni: più raggiungibili significa più esposti?
Anthony Towns ha chiesto nel thread se accettare connessioni in entrata casuali sia davvero desiderabile per la maggior parte dei nodi, perché può essere uno strumento per gli attaccanti. Il 17 ottobre, a proposito della variante 6, ha stimato che un attaccante capace di annunciare circa 10.000 porte sarebbe tra i primi abbinamenti per la maggior parte dei nodi onesti: in uno scenario con 100.000 nodi, circa l’85% dei nodi onesti avrebbe entrambi i primi due abbinamenti in mano all’attaccante.
Towns ha poi indicato due obiettivi: avere un’alta probabilità di collegarsi a un nodo onesto (contro la censura) e una bassa probabilità di collegarsi a un attaccante specifico (contro spionaggio, DoS ed exploit mirati). Per lui l’hole punching rischia di peggiorare il secondo. Il 3 novembre, secondo Optech, si è chiesto se le recenti vulnerabilità nello stack TCP e nel protocollo rendano più sicuro, per gli utenti domestici, non accettare connessioni in entrata. Per altri casi di sicurezza dei nodi, abbiamo raccontato le tre falle di Bitcoin Core rese pubbliche.
Jonathan Harvey-Buschel ha citato dati secondo cui i nodi onesti sono meno raggiungibili di quelli controllati da attaccanti, e ha preferito il coordinamento tramite il servizio Tor del nodo, riferisce Optech. Il 18 ottobre 0xB10C aveva proposto per la variante 6 una «bacheca» (message board) tenuta da nodi in ascolto, che registra l’IP di un nodo di casa solo se coincide con quello che vede. Il 21 ottobre ha ammesso un limite della versione senza bacheca, affidata al normale scambio di indirizzi: i nodi di casa hanno solo 8 connessioni e ricevono gli annunci molto meno dei nodi in ascolto, quindi pensa che sarebbe probabilmente molto inaffidabile.
Secondo 0xB10C, emerso da una discussione di persona, oggi la rete dipende in parte da nodi ospitati da Hetzner, AWS, Google Cloud e Digital Ocean per offrire connessioni in entrata. Se quei fornitori non accettassero più nodi, secondo lui servirebbe qualcosa che colleghi tra loro i nodi di casa, e l’hole punching sposterebbe la topologia da «hub» a «maglia» (mesh). Towns ha replicato che oggi la rete è già a due livelli, con una maglia di nodi in ascolto. Sono ragionamenti dei due sviluppatori, non dati misurati.
Cosa aspettarsi
Per ora si lavora su carta e su codice sperimentale, e Optech riferisce che la discussione è ancora aperta. Tra le domande lasciate da 0xB10C a maggio ci sono come classificare in Bitcoin Core una connessione bucata (in entrata o in uscita), quanto siano diffusi i NAT adatti e se la funzione risolva un problema reale. Il 2 novembre ha linkato nel thread anche la discussione sul tema al CoreDev di Tokyo 2026.
Nella stessa newsletter, Optech riprende anche il BIP-54, il Consensus Cleanup, altro tema di sviluppo che abbiamo già raccontato.
Domande frequenti sui nodi Bitcoin domestici
Che cos’è un nodo Bitcoin raggiungibile?
È un nodo che accetta connessioni in entrata da altri nodi. Un nodo dietro il router di casa di solito riesce solo a collegarsi verso gli altri, riferisce Optech, a meno che il router consenta l’apertura di una porta (per esempio con NAT-PMP).
Che cos’è l’hole punching TCP?
È una tecnica con cui due computer dietro un NAT aprono nello stesso momento una connessione l’uno verso l’altro, così che ciascun router lasci passare il traffico dell’altro. Funziona solo con certi tipi di NAT, e per Bitcoin è ancora una proposta in discussione.
Questa proposta cambia le regole di Bitcoin?
No. Riguarda il modo in cui i nodi si collegano tra loro, non le regole di validazione dei blocchi: Optech la tratta nella sezione delle notizie e non in quella dedicata ai cambi di consenso.
Per seguire le novità sullo sviluppo di Bitcoin in tempo reale, scarica l’app BitcoinLive24.
