Bob ha custodito 0,5 Bitcoin per tre anni nel suo cold wallet. Non ha mai venduto, non ha mai mosso un sat. L’8 agosto 2026, nel pieno di un tranquillo pomeriggio estivo, decide di spostare quei fondi su un nuovo indirizzo. Non sa ancora che, in quel preciso momento, due reti Bitcoin coesistono — e che la sua transazione potrebbe viaggiare su entrambe, senza che lui lo sappia mai.
La storia di Bob non è un esperimento mentale. È lo scenario concreto descritto da Murch (Mark Erhardt), sviluppatore Bitcoin Core e ricercatore di Chaincode Labs, in un post pubblicato il 6 luglio 2026 che sta circolando nella community. Un avvertimento chiaro, tecnico, ma con implicazioni pratiche per chiunque detenga Bitcoin.
Il Countdown al Blocco 961.632: Cosa Sta per Succedere
La data cerchiata sul calendario è quella intorno all’8 agosto 2026, al blocco 961.632. È il momento in cui i nodi BIP-110/RDTS (Reduced Data Temporary Softfork, ovvero “softfork temporanea per la riduzione dei dati”) inizieranno ad applicare la signaling obbligatoria per la loro proposta controversa.
RDTS è un tentativo di limitare l’uso dei blocchi Bitcoin per dati come le iscrizioni Ordinals e gli OP_RETURN. Il problema? Il supporto tra i miner è inferiore all’1% dell’hashrate globale. Come abbiamo spiegato nell’analisi del dibattito BIP-110 su BitcoinLive24, si tratta di una minoranza che vuole imporre nuove regole al resto della rete — e che difficilmente riuscirà nel suo intento.
Ma proprio questo è il paradosso: anche una fork destinata a fallire può creare un periodo di rischio reale per i detentori ordinari di Bitcoin. Il motivo ha a che fare con come funziona la trasmissione delle transazioni su una rete divisa.
Due Reti, una Transazione: Il Meccanismo del Replay Attack
Quando i nodi RDTS iniziano a rifiutare i blocchi non-segnalanti, la rete si divide temporaneamente in due chaintip (due versioni concorrenti della blockchain). Da quel momento in poi:
- La chain Bitcoin principale continua con blocchi ogni ~10 minuti, esattamente come sempre
- La chain RDTS rallenta drasticamente a circa 1 blocco al giorno, perché i miner che la supportano sono meno dell’1% del totale dell’hashrate
Il problema nasce dal fatto che, durante questa fase, le transazioni firmate e valide su una chain sono tecnicamente valide anche sull’altra — salvo che almeno un input della transazione non sia già stato speso sull’altro ramo. In assenza di meccanismi di protezione dai replay, qualsiasi transazione può essere “replicata”: trasmessa dai nodi dell’altra rete senza che il mittente ne sia consapevole.
Il risultato? Bob invia i suoi 0,5 BTC a un nuovo indirizzo sulla chain principale. La transazione viene intercettata e ritrasmessa sulla chain RDTS. Bob ha ora inviato i suoi fondi su entrambe le catene contemporaneamente — verso indirizzi che potrebbero non essere i suoi.
La Storia di Bob — e la Transazione che Viaggia su Due Catene
Murch usa nell’articolo originale proprio l’esempio di Bob per illustrare la tecnica di “coin splitting” — ovvero come separare i propri UTXO (Unspent Transaction Output, le “monete” spendibili) su una chain dall’altra, rendendoli immuni al replay. La meccanica è elegante quanto precisa.
Bob possiede un output identificato come tx_B:0. Vuole assicurarsi che i suoi Bitcoin esistano in modo indipendente sui due rami. Ecco la procedura di protezione:
- Crea una transazione
tx_Ccon feerate (commissione per byte) basso, che invia i fondi a sé stesso sulla chain Bitcoin principale - Attende che
tx_Cvenga confermata dalla chain principale con diverse conferme - Crea poi una transazione
tx_Dad alto feerate che spende lo stessotx_B:0, ma verso un indirizzo diverso — questa volta per essere inclusa sulla chain RDTS
Poiché le due transazioni spendono lo stesso UTXO ma producono output diversi, solo una delle due può essere valida su ciascun ramo. Una volta che entrambe sono confermate sulle rispettive chain, Bob ha separato con successo i suoi Bitcoin: da quel momento in poi qualsiasi transazione che parte da questi nuovi output eredita automaticamente la protezione dal replay.
Vale la pena sottolineare un dettaglio tecnico: i blocchi Coinbase (i premi ricevuti dai miner per aver estratto un blocco) sono per definizione intrinsecamente unici su ciascuna chain, e possono quindi essere usati per “propagare” la protezione agli output successivi. I miner in questo scenario hanno un vantaggio naturale rispetto ai semplici detentori.
Le Strategie per Proteggersi Prima che Sia Troppo Tardi
Per i detentori di Bitcoin che non sono miner, le opzioni pratiche sono diverse, con livelli di complessità variabili. La tabella qui sotto riassume le principali strategie identificate da Murch e dalla community:
| Strategia | Come funziona | Difficoltà | Per chi |
|---|---|---|---|
| Coin splitting via fee differential | Tx basso feerate su Bitcoin, poi alto feerate con stesso UTXO su RDTS | Media — richiede wallet avanzato | Utenti self-custody avanzati |
| Non muovere fondi durante il fork | Aspettare che la chain RDTS si estingua (stima: pochi giorni) | Bassa — nessuna azione tecnica | Holder ordinari, la scelta più sicura |
| Fondi su exchange custodial | L’exchange gestisce il rischio per conto dell’utente | Nulla per l’utente | Chi usa Coinbase, Kraken, Binance ecc. |
| Uso di output Coinbase maturi | Block reward intrinsecamente chain-specifici dopo 100 conferme | Alta — solo per miner | Miner con hashrate attivo |
La strategia più semplice per la grande maggioranza dei detentori? Non effettuare transazioni nei giorni attorno all’8 agosto 2026. Con un hashrate di supporto RDTS inferiore all’1%, la catena alternativa si esaurirà in tempi rapidi. La finestra di rischio è concreta ma breve.
Il 2017 Come Specchio: Bitcoin Cash e il Precedente Storico
Chi ha vissuto il fork di Bitcoin Cash nell’agosto 2017 ricorda bene il caos che seguì. Quando la rete si divise in due chain — Bitcoin e Bitcoin Cash — le transazioni erano inizialmente valide su entrambi i rami. Lo stesso identico problema di replay. La soluzione trovata dal mercato fu pragmatica ma dolorosa: exchange e servizi di terze parti sospesero i prelievi Bitcoin per giorni, fino a quando la situazione non si stabilizzò e i due ecosistemi si separarono con chiarezza.
Come emerge dall’analisi dello stress sui miner Bitcoin nel 2026 che abbiamo pubblicato su BitcoinLive24, la rete Bitcoin ha già attraversato momenti di grande tensione interna. Il 2017 insegna che i fork — anche quelli “minori” o destinati a fallire — possono avere conseguenze pratiche per i detentori ordinari.
Questa volta, però, il contesto è radicalmente diverso. Con RDTS che raccoglie meno dell’1% del supporto dei miner, nessuno si aspetta che gli exchange sospendano i servizi. Non c’è un’economia attorno alla chain RDTS, non ci sono grandi portafogli che vogliono un “airdrop” da vendere. La finestra di vulnerabilità sarà probabilmente misurata in giorni, non settimane.
Circolano tuttavia voci nella community: i sostenitori di RDTS starebbero valutando un hard fork per ridurre la difficoltà o cambiare l’algoritmo di proof-of-work come piano B. Se questa opzione venisse perseguita, la chain minoritaria potrebbe trasformarsi in una vera e propria forkcoin — e il rischio replay diventerebbe più duraturo e strutturato.
Cosa Insegna Questa Storia al Detentore Bitcoin Moderno
La vicenda del fork RDTS di agosto 2026 non è una storia di catastrofe imminente. È piuttosto una storia di consapevolezza: la rete Bitcoin è robusta, ma i dettagli tecnici contano — anche per chi non è uno sviluppatore, anche per chi detiene Bitcoin senza mai toccarli.
Il fatto che un ricercatore come Murch si prenda la briga di scrivere un post tecnico accessibile — usando “Bob” come protagonista per spiegare un concetto astratto come il replay attack — è parte integrante della cultura Bitcoin. La community si auto-avverte, si documenta, si protegge. Non è un sistema centralizzato dove una banca ti chiama per dirti “attenzione, domani potrebbero esserci problemi con il tuo conto”.
Quella capacità di auto-organizzazione è, probabilmente, uno degli aspetti più affascinanti del protocollo. Il rischio c’è, ma anche la risposta — ed è arrivata prima ancora che il problema si manifestasse.
BitcoinLive24 seguirà l’evolversi della situazione nelle settimane che precedono agosto 2026. Se vuoi essere aggiornato in tempo reale sugli sviluppi del protocollo Bitcoin, scarica l’app BitcoinLive24 e riceverai notifiche istantanee.
FAQ sul Fork RDTS e il Rischio Replay per i Detentori Bitcoin
Cos’è un replay attack nel contesto del fork RDTS Bitcoin?
Un replay attack nel contesto del fork RDTS è quando una transazione valida su una chain viene copiata e trasmessa anche sull’altra chain del fork. Nel caso del fork RDTS di agosto 2026, una transazione inviata sulla chain Bitcoin principale potrebbe essere automaticamente ripetuta sulla chain RDTS, muovendo i fondi in entrambe le reti senza che il mittente lo sappia.
Devo preoccuparmi del fork RDTS se tengo Bitcoin su un exchange?
Se tieni Bitcoin su un exchange centralizzato (custodia di terze parti), sei generalmente protetto: sarà l’exchange a gestire il rischio replay per conto tuo, come avvenne nel 2017 con il fork Bitcoin Cash. Il rischio replay riguarda principalmente chi gestisce autonomamente i propri Bitcoin in self-custody. La soluzione più semplice per gli holder è non effettuare transazioni nei giorni intorno all’8 agosto 2026.
Quanto durerà il rischio replay del fork RDTS?
Il rischio replay si esaurirà quando la chain RDTS si estinguerà — probabilmente nel giro di pochi giorni dall’attivazione al blocco 961.632. Con meno dell’1% dell’hashrate che supporta RDTS, la chain alternativa produrrà circa 1 blocco al giorno contro i normali 144 blocchi Bitcoin. La finestra di vulnerabilità sarà breve ma reale: la consapevolezza è la migliore protezione.
