Stratum V2 vs V1 — La rivoluzione del protocollo

Stratum è il protocollo che collega i miner ai pool — e la versione su cui gira ancora la maggior parte di Bitcoin, Stratum V1, risale al 2012. Trasmette le credenziali in chiaro, lascia al pool la scelta di quali transazioni entrano in ogni blocco e concentra un controllo che Bitcoin era pensato per distribuire. Stratum V2 risolve tutti e tre i problemi: cifratura end-to-end, formato binario compatto e — soprattutto — job negotiation, che permette ai singoli miner di costruire i propri template di blocco. A maggio 2026 sette pool che rappresentano circa il 75% dell’hashrate di rete hanno sostenuto lo standard: il più grande spostamento verso la decentralizzazione che il mining abbia visto da anni.

In sintesi

• Il difetto di fondo di V1 è la centralizzazione: il pool costruisce ogni template di blocco, quindi una manciata di operatori decide cosa entra nella maggior parte dei blocchi Bitcoin.
• La funzione chiave di V2 è la job negotiation: i miner che gestiscono un proprio nodo scelgono le proprie transazioni, spezzando il controllo dei pool sul contenuto dei blocchi.
• La cifratura conta soprattutto per i miner domestici: il testo in chiaro di V1 permette il dirottamento silenzioso dell’hashrate su reti non fidate; la cifratura Noise di V2 lo rende crittograficamente impossibile.
• Il 2026 è stato il punto di svolta: a maggio sette pool (~75% dell’hashrate, inclusi Foundry e AntPool) sono entrati nel working group di Stratum V2 — dopo anni da progetto di nicchia.
• Nel solo mining la posta in gioco è diversa: un solo pool non custodial non controlla mai né i tuoi fondi né il contenuto dei tuoi blocchi, quindi i vantaggi di V2 sono soprattutto cifratura, latenza e compatibilità futura.

Questo articolo spiega come funziona Stratum, cosa cambia V2, chi lo supporta oggi e cosa ci aspetta — per poi chiudere con un’ampia appendice sulla minaccia quantistica, perché a marzo 2026 Google Quantum AI ha pubblicato una ricerca che ha compresso i tempi previsti per quando le firme di Bitcoin potrebbero cedere, e la comunità di sviluppo sta ora redigendo difese post-quantistiche (BIP-360, BIP-361, Hourglass) in risposta.

Cos’è davvero Stratum

Stratum è un protocollo che collega due parti: il mining pool (gestisce i nodi Bitcoin, costruisce i template di blocco, distribuisce il lavoro, valida le share, paga le ricompense) e il miner (riceve un header di blocco da calcolare, itera il nonce, invia i risultati). Ogni Antminer, Bitaxe e Whatsminer del pianeta parla Stratum. Senza di esso i pool non potrebbero esistere — e senza i pool, la maggior parte dei miner non tollererebbe la varianza del fare da soli su larga scala. Il compito del protocollo sembra semplice: consegnare il lavoro giusto al miner giusto, abbastanza in fretta perché nessuno sprechi potenza su job scaduti. Ma i dettagli — formato dei messaggi, cifratura e chi controlla il contenuto dei blocchi — si rivelano enormemente importanti.

Cosa non va in Stratum V1?

Stratum V1, creato da Marek “Slush” Palatinus nel 2012, è un semplice protocollo JSON-RPC su TCP puro: rapido da implementare, facile da debuggare. Quattordici anni di contesto ne hanno esposto diversi problemi strutturali.

1. Comunicazione in chiaro

V1 manda tutto in JSON non cifrato — credenziali del pool, indirizzo wallet, nome del worker, invii di share — leggibile da chiunque si trovi sul percorso di rete. Ancora più pericoloso, il testo in chiaro abilita il dirottamento di hashrate: un attaccante che controlla un segmento di rete tra te e il pool può reindirizzare silenziosamente le tue share verso un pool proprio. Braiins ha documentato casi sospetti da miner in Cina, Kazakistan, Russia ed Europa — sottrarre appena l’1-2% dell’hashrate basta a intaccare la redditività senza risultare evidente alla vittima.

2. Selezione delle transazioni controllata dal pool

Con V1 il pool costruisce il template del blocco e il miner calcola semplicemente l’hash di qualunque header arrivi. È il pool a decidere quali transazioni entrano nel blocco. Poiché circa cinque pool controllano il 70% della potenza di calcolo, una manciata di operatori decide di fatto il contenuto della maggior parte dei blocchi Bitcoin. Se un governo preme su un pool perché censuri certe transazioni, ogni miner su quel pool partecipa involontariamente. È già accaduto in forma limitata: Marathon ha minato blocchi “puliti” conformi all’OFAC nel 2023 come esperimento, e i miner su un pool che filtra non hanno alcun modo, a livello di protocollo, per sottrarsi.

3. Overhead JSON e proliferazione di connessioni

JSON è leggibile dall’uomo, il che è ottimo per il debug e sprecone per la banda — nomi dei campi e virgolette aggiungono il 30-40% di overhead rispetto a un equivalente binario. E ogni ASIC apre la propria connessione TCP, quindi una farm da 1.000 macchine mantiene 1.000 sessioni Stratum simultanee. Invisibile per un Bitaxe; misurabile per una farm grande.

4. Nessuna integrità firmware a livello di protocollo

V1 non può verificare che un miner stia eseguendo firmware noto e integro. Un firmware compromesso può inviare share sottilmente errate che sembrano valide ma costano denaro al pool, e rilevarle richiede audit fuori dal protocollo.

Come V1 è sopravvissuto lo stesso: BIP-310

Dati quattro difetti strutturali, è lecito chiedersi come un protocollo del 2012 trasporti ancora la maggior parte dell’hashrate di Bitcoin. La risposta è BIP-310, “Stratum protocol extensions” — una proposta Informational a livello Applications, assegnata il 10 marzo 2018 e scritta da Pavel Moravec e Jan Čapek di Braiins, le stesse due persone che l’anno successivo avrebbero specificato Stratum V2.

Il problema che BIP-310 ha risolto è che V1 non aveva modo di crescere. Manda a un server un messaggio che non riconosce e molte implementazioni semplicemente chiudono la connessione: non esisteva quindi una via sicura per proporre una nuova funzione. Peggio, la funzione di cui i miner avevano urgente bisogno — il version rolling — era incompatibile all’indietro per natura: il miner non aveva un campo in cui riportare una versione di blocco modificata, e il server non aveva modo di dirgli quali bit fosse sicuro toccare.

Un messaggio per negoziarle tutte

La risposta di BIP-310 è stata un unico nuovo messaggio, mining.configure, che secondo la specifica DOVREBBE essere il primo messaggio inviato dal miner una volta stabilita la connessione — prima della subscribe, prima dell’autorizzazione. Il miner dichiara cosa sa fare e chiede ciò che vuole; il server risponde con ciò che permetterà davvero, funzione per funzione. Ogni estensione riceve un namespace, quindi i parametri si leggono come version-rolling.mask, minimum-difficulty.value e così via, e ciascuno restituisce true, false o una stringa di errore. L’obiettivo di progetto era esplicito: rendere possibile aggiungere funzioni in seguito senza aggiungere altri messaggi.

Quell’unico meccanismo porta con sé quattro estensioni:

Come si concorda davvero la maschera di versione

La negoziazione è più sottile di un “chiedi e ricevi”, e il dettaglio spiega molti comportamenti reali. Il miner invia una maschera dei bit che è capace di modificare; il server tiene la propria maschera dei bit che è disposto a concedere — alcuni bit di versione devono restare fissi perché il blocco sia valido o per la segnalazione dei soft fork. Il risultato è l’intersezione delle due. Un miner può dichiarare l’intero intervallo a 16 bit 1fffe000 e ricevere indietro 18000000 — appena due bit. Questa è una negoziazione riuscita, non un fallimento.

Insieme alla maschera, il miner invia version-rolling.min-bit-count: il numero minimo di bit che gli serve per fare rolling in modo efficiente in hardware. Se il pool non può concederne altrettanti, la specifica è categorica: il pool NON DOVREBBE chiudere la connessione — il miner semplicemente lavora in modalità degradata, senza piena potenza di hashing. Quell’indicazione è il motivo per cui una macchina non allineata rende meno in silenzio invece di fallire rumorosamente, ed è esattamente il tipo di comportamento che manda le persone a caccia di un guasto hardware inesistente.

Altri due meccanismi da conoscere. Il server può cambiare la maschera in qualsiasi momento della sessione con mining.set_version_mask, e la nuova maschera ha effetto immediato anziché dal job successivo. E una volta attivo il version-rolling, mining.submit guadagna un sesto parametro — version_bits, dopo nome del worker, ID del job, extranonce2, ntime e nonce. Il miner può impostare solo i bit concessi dal server; qualsiasi cosa fuori dalla maschera invalida la share. Il server ricostruisce poi la versione del blocco prendendo il valore originale del job per ogni bit fuori dalla maschera e il valore del miner per ogni bit al suo interno.

Quali bit siano sicuri da modificare è una questione a parte, a cui risponde una specifica gemella — BIP-320, citata in BIP-310 quando era ancora una bozza senza numero. Il nostro approfondimento su AsicBoost copre la meccanica a livello di bit e la storia dei brevetti che vi sta dietro.

L’ironia da cogliere: BIP-310 è ancora formalmente una Draft, otto anni dopo, ed è ciò che ha permesso a un protocollo senza cifratura e senza estensibilità di restare praticabile per un altro decennio. Stratum V2 rende superfluo l’intero apparato — version rolling, gestione della difficoltà, aggiornamenti dell’extranonce e identificazione dei dispositivi fanno parte del modello a canali di V2, negoziati nell’handshake senza alcuna aggiunta posticcia. Il meccanismo di estensione che ha salvato V1 è precisamente ciò di cui V2 non ha più bisogno.

Cosa cambia Stratum V2?

Stratum V2 è stato progettato da zero per risolvere ognuno di questi problemi. È stato specificato per la prima volta a novembre 2019 dai cofondatori di Braiins Jan Capek e Pavel Moravec insieme allo sviluppatore di Bitcoin Core Matt Corallo; il working group è stato cofondato da Braiins e Spiral nel 2022. La Stratum V2 Reference Implementation (SRI) è maturata nel 2024-2026, e Bitcoin Core v30 ha aggiunto il supporto sperimentale a V2.

Cifratura end-to-end (protocollo Noise)

Ogni connessione V2 è cifrata usando il framework del protocollo Noise — la stessa base della VPN WireGuard. Dopo un handshake autenticato, tutti i messaggi sono cifrati (ChaCha20-Poly1305 o AES-256-GCM). In pratica: chi osserva la rete non può vedere il tuo pool, il tuo wallet o il tuo worker; il dirottamento di hashrate diventa crittograficamente impossibile; e le credenziali non compaiono mai in transito. I pool pubblicano chiavi pubbliche di lungo termine, e i miner verificano di parlare con il pool legittimo e non con un uomo nel mezzo — lo stesso modello di sicurezza di SSH.

Protocollo binario (efficiente)

V2 sostituisce JSON con un formato binario compatto: messaggi più piccoli (circa il 30% di banda in meno), parsing più veloce, meno carico CPU da entrambi i lati. Per una farm grande sono risparmi infrastrutturali reali; per un miner domestico su una connessione limitata significa job che arrivano prima e meno share stale.

Job negotiation — la funzione decisiva

È questo che rende V2 storicamente importante, non solo tecnicamente migliore. Con il job negotiation protocol, i miner possono gestire un proprio nodo Bitcoin completo e costruire localmente i propri template di blocco — scegliendo quali transazioni includere, ottimizzando per le commissioni più alte o applicando politiche proprie. Il pool non detta più il contenuto del blocco; si limita a validare la proof-of-work e a pagare i blocchi validi. Il ruolo del pool si riduce da “decisore” ad “aggregatore di share e validatore di PoW”, e il miner riacquista sovranità su ciò che la sua potenza di calcolo protegge.

Tre conseguenze dirette: resistenza alla censura (un governo può fare pressione su un pool, ma non sui singoli miner che gestiscono i propri template — finché abbastanza hashrate negozia i propri job, le transazioni censurate finiscono comunque da qualche parte), ottimizzazione delle commissioni (i miner con un proprio mempool possono catturare le transazioni con commissioni più alte, specie nei periodi di congestione) e decentralizzazione dei pool (i pool diventano infrastruttura di consumo, riducendo l’incentivo al consolidamento).

In sostanza: la job negotiation di Stratum V2 è il cambiamento più significativo nei protocolli di mining dai tempi di SegWit. Disaccoppia la funzione economica dei pool (attenuare la varianza, pagare le ricompense) da quella sensibile alla censura (decidere il contenuto dei blocchi) — e restituisce la seconda ai miner.

Stato dell’adozione (metà 2026)

Per gran parte della sua vita, l’adozione di V2 è stata scarsa — uno standard di nicchia sostenuto da pochi pool. A inizio 2026 solo una stima del 15-20% dell’hashrate di rete si connetteva effettivamente via V2, per lo più per i benefici della cifratura più che per la job negotiation. Poi il quadro è cambiato bruscamente.

A maggio 2026, sette dei maggiori mining pool — Foundry, AntPool, F2Pool, SpiderPool, MARA Pool, Block Inc e DMND — sono entrati nel working group di Stratum V2, rappresentando insieme quasi il 75% dell’hashrate globale. Secondo i dati Hashrate Index citati all’epoca, la sola Foundry valeva circa il 34%, AntPool ~14%, F2Pool ~11% e SpiderPool ~10,5%. Fondamentale: V2 non riduce la concentrazione di hashrate — Foundry mantiene la stessa quota — ma cambia chi decide il contenuto dei blocchi, che è la parte di cui la comunità si preoccupa davvero. CoinDesk l’ha definita la più grande mossa verso la decentralizzazione che il mining avesse visto da anni.

L’impegno è una linea di partenza, non un traguardo. “Entrare nel working group” significa sostenere lo standard e iniziare il rilascio — non che oggi il 75% dell’hashrate usi la job negotiation di V2. La maggior parte dei miner su V2 accetta ancora template costruiti dal pool e lo usa per cifratura ed efficienza. Ma con Foundry e AntPool a bordo, un protocollo rimasto ai margini per anni ha improvvisamente la portata per diventare l’impostazione predefinita.

Supporto hardware e firmware

È la parte della storia di V2 riportata in modo più scorretto, anche in versioni precedenti di questo articolo. V2 è una capacità del firmware, e ad agosto 2026 esattamente tre famiglie di firmware la implementano nativamente.

• Braiins OS+ (26.07 consigliata) — l’unico firmware commerciale per Antminer con client V2 nativo, dall’S9 all’S21 XP. È ciò che porta su V2 la famiglia di ASIC più diffusa al mondo: un solo reflash, nessun hardware nuovo.
• AxeOS 2.14.0+ — V2 nativo su Bitaxe, rilasciato a giugno 2026, con consolidamento nella 2.15.0.
• Firmware NerdQAxe 1.0.37+ — V2 nativo su NerdAxe, NerdQAxe+/++ e NerdOCTAxe.
• Auradine FluxOS — tra i primi a offrire V2 nativo sulla linea Teraflux.
• Firmware stock Bitmain — solo V1, su ogni modello inclusi S21 e S23. Nessun Antminer esce di fabbrica con Stratum V2 funzionante.
• Stock WhatsMiner, VNish, LuxOS, Canaan/Avalon stock — solo V1.

Due correzioni da dire chiaramente, perché entrambe circolano molto e costano una serata. Nessun Antminer supporta V2 nel firmware stock — alcune build espongono un’impostazione dall’aspetto V2 che non negozia mai una sessione reale, il che è peggio che non offrire nulla, perché il miner sembra configurato mentre gira in silenzio su V1. E Bitaxe e NerdQAxe supportano V2 nativamente, e lo fanno da giugno 2026 — le guide scritte prima, questa inclusa, dicevano il contrario.

Per la configurazione passo passo di ciascuno di essi — inclusi i dettagli sulla authority key che decidono se la tua sessione è solo cifrata o davvero autenticata — vedi la nostra guida al solo mining in Stratum V2.

Il ponte del Translator Proxy

Per l’hardware più vecchio che non sa parlare V2 nativamente, SRI fornisce un Translator Proxy. Il tuo ASIC V1 esistente si collega al proxy sulla rete locale; il proxy parla V1 al miner e V2 al pool, dandoti i benefici di cifratura e banda senza cambiare firmware. La job negotiation richiede comunque V2 nativo, ma il proxy copre il livello di cifratura per qualsiasi macchina.

Quanto profitto aggiunge davvero V2?

Vedrai citare spesso la cifra “V2 aumenta il profitto fino a ~7%”. È un limite superiore in condizioni ideali, e si scompone all’incirca così:

• ~1-2% dalla cifratura — eliminando il dirottamento silenzioso che affligge V1 non cifrato su reti non fidate
• Qualche punto percentuale dalla selezione delle transazioni — gestire un proprio mempool per catturare le transazioni con commissioni più alte, specie durante la congestione
• ~1-2% da meno share stale — la minore latenza e l’efficienza binaria di V2 significano meno lavoro rifiutato

In pratica la maggior parte dei miner vedrà cifre a una cifra bassa — e la fetta della cifratura si materializza solo se eri effettivamente esposto al dirottamento. Tratta il numero da titolo come un tetto, non come una promessa.

Cosa significa per i miner SoloFury

SoloFury serve Stratum V2 in produzione da agosto 2026, su nove region in cinque continenti. V1 e V2 girano sulla stessa porta — il pool rileva quale protocollo parla il tuo miner e risponde di conseguenza — così una flotta mista punta a un solo indirizzo e non c’è nulla da riconfigurare. V2 è disponibile per BTC; BCH, BC2, BCH2 e XEC continuano su V1 con pieno version-rolling, quindi ogni ASIC moderno mantiene il suo guadagno AsicBoost su qualsiasi catena tu punti.

Ecco il punto chiave per chi mina solo: nel solo mining il pool non controlla i tuoi fondi e non si frappone tra te e la tua ricompensa. Imposti come username stratum il tuo indirizzo wallet, il pool assembla un blocco, tu lo trovi, e la coinbase della rete ti paga direttamente. Non c’è custodia da compromettere né saldo da congelare. Il solo mining era già strutturalmente allineato agli obiettivi di decentralizzazione di V2 — ed è per questo che, per i solo miner, i guadagni di V2 sono cifratura, latenza e una capacità che il protocollo abilita in modo unico: con un canale extended e la decodifica della coinbase, il tuo stesso miner mostra gli output del blocco prima che tu li calcoli, così puoi verificare che la ricompensa sia intestata a te invece di credere al pool sulla parola. (Sul perché AsicBoost sia hashrate gratuito a prescindere dalla versione di protocollo, vedi il nostro approfondimento su AsicBoost.)

Appendice: la minaccia quantistica per Bitcoin

A fine marzo 2026 Google Quantum AI — insieme al crittografo di Stanford Dan Boneh e a Justin Drake della Ethereum Foundation — ha pubblicato un whitepaper, The Quantum Threat to Elliptic Curve Cryptocurrencies, che ha riscritto la discussione. I modelli precedenti presupponevano milioni di qubit per violare le firme di Bitcoin. La nuova stima di Google: meno di 500.000 qubit fisici — circa 20 volte meno della cifra del 2019 di ~20 milioni — potrebbero decifrare una chiave privata Bitcoin in circa nove minuti, una volta che una transazione espone la chiave pubblica. (Questa appendice è contesto tecnico, non consulenza finanziaria o di sicurezza. La minaccia è reale ma non imminente — vedi gli scettici più sotto.)

In cosa consiste davvero la minaccia

Bitcoin si appoggia a due primitive crittografiche. SHA-256 (proof-of-work e alberi di Merkle) è resistente ai quantistici a ogni fine pratico — violarlo è astronomicamente lontano, e i tuoi ASIC non ne risentono. secp256k1 ECDSA e Schnorr (le firme digitali che proteggono le transazioni) sono la parte vulnerabile: l’algoritmo di Shor, su un computer quantistico sufficientemente grande, può derivare una chiave privata da una chiave pubblica esposta.

La sfumatura che la maggior parte delle coperture sbaglia: una chiave pubblica è esposta solo quando spendi da un indirizzo (o usi un formato legacy che la memorizza direttamente). A marzo 2026 oltre un terzo di tutti i bitcoin — circa 6,9 milioni di BTC — si trova in indirizzi con chiavi pubbliche già rivelate on-chain. Circa 1,7 milioni di questi sono in antichi output pay-to-public-key (P2PK), inclusi circa un milione ritenuti di Satoshi. Le monete in indirizzi moderni mai riutilizzati mantengono la chiave pubblica hashata e nascosta finché non spendi.

”Raccogli ora, decifra dopo”

Il motivo per cui gli sviluppatori dicono che l’orologio è partito, pur non esistendo un computer quantistico all’altezza, è che le chiavi pubbliche esposte sono permanenti e pubbliche. Un avversario può archiviarle oggi e violarle quando arriverà l’hardware — e un attaccante paziente potrebbe calcolare le chiavi in silenzio e prosciugare i fondi mesi dopo, così il “Q-Day” potrebbe essere riconosciuto solo a posteriori. Ogni chiave esposta ora è un bersaglio futuro permanente.

BIP-360: un tipo di indirizzo resistente ai quantistici

BIP-360 introduce un nuovo tipo di output — descritto come Pay-to-Quantum-Resistant-Hash (P2QRH) o Pay-to-Merkle-Root, con un nuovo prefisso di indirizzo bc1z. Si comporta in modo simile a Taproot ma sostituisce l’elemento a curva ellittica sfruttabile con firme post-quantistiche approvate dal NIST (come SPHINCS+ basato su hash e CRYSTALS-Dilithium basato su reticoli). Il compromesso è la dimensione: le firme post-quantistiche vanno da qualche kilobyte (Dilithium) a molto di più (SPHINCS+), contro circa 64-72 byte per ECDSA — quindi i blocchi si appesantiscono e la capacità si stringe durante qualsiasi migrazione. BIP-360 è stato integrato nel repository BIP di Bitcoin a febbraio 2026, con implementazioni già in esecuzione su testnet, sebbene non sia ancora attivato come soft fork.

BIP-361: il tramonto controverso

BIP-361, “Post Quantum Migration and Legacy Signature Sunset”, scritto dal CTO di Casa Jameson Lopp e da cinque coautori (bozza pubblicata ad aprile 2026), propone un piano a fasi per forzare la migrazione via dalle firme vulnerabili:

• Fase A (circa tre anni dopo l’attivazione di un tipo di indirizzo post-quantistico): bloccare l’invio di fondi verso tipi di indirizzo vulnerabili ai quantistici, spingendo tutti verso formati sicuri.
• Fase B (circa cinque anni dopo l’attivazione): un soft fork a data fissa invalida del tutto le spese ECDSA/Schnorr. Qualsiasi UTXO non migrato entro quel momento diventa non spendibile.
• Fase C (opzionale, allo studio): un percorso di recupero che permette ai possessori di dimostrare la proprietà tramite una prova a conoscenza zero del proprio seed BIP-39 — senza esporre le chiavi.

La Fase B congela di fatto i ~1,7 milioni di BTC antichi i cui proprietari non possono migrare, inclusi quelli di Satoshi. I critici definiscono il congelamento delle monete — anche a scopo protettivo — una violazione del diritto di proprietà e un precedente pericoloso. I sostenitori ribattono che l’alternativa è peggiore: lasciare quelle monete a un futuro attaccante quantistico che le raccolga e le riversi sul mercato, facendo crollare fiducia e prezzo. Lopp lo inquadra come teoria dei giochi; la bozza esplicitamente non è posizionata per l’attivazione, e Bitcoin Core resta prudente. È la proposta più contestata dell’insieme.

Hourglass e le alternative

Un approccio in stile Hourglass è il cugino più gentile: invece di congelare del tutto le monete vulnerabili, limiterebbe la velocità con cui possono essere spese, riducendo la rapidità con cui un ladro quantistico potrebbe prosciugarle e riversarle sul mercato, senza escludere permanentemente i proprietari onesti. Separatamente, un ricercatore di StarkWare ha pubblicato uno schema per rendere le nuove transazioni sicure dai quantistici già oggi tramite prove basate su hash, opzionale e senza soft fork. Ed esistono catene resistenti ai quantistici costruite apposta (QRL usa firme XMSS basate su hash, per esempio), sebbene nessuna abbia una quota significativa accanto a Bitcoin. La scommessa prevalente è che Bitcoin si aggiorni in tempo.

Quanto è vicina la minaccia, davvero?

Non vicina in termini di hardware. I computer quantistici odierni lavorano nell’ordine di centinaia di qubit logici; violare secp256k1 ne richiede migliaia di logici (e centinaia di migliaia di fisici) con tassi di errore che nessuno ha ancora raggiunto su scala. Le stime presuppongono inoltre imprese ingegneristiche notevoli che potrebbero richiedere molti anni. Le voci che invitano alla calma sono autorevoli: Adam Back di Blockstream ha sostenuto nel 2026 che la minaccia è probabilmente lontana decenni e che la migrazione dovrebbe essere graduale, mentre la società di consulenza McKinsey ha ipotizzato una finestra 2027-2030 per una potenziale fattibilità, e un coautore di BIP-360 stima che una migrazione completa potrebbe richiedere di per sé circa sette anni. Il riassunto onesto: reale, presa sul serio, e non un problema del 2026 — ma uno che Bitcoin ha scelto di iniziare a risolvere presto, perché la migrazione è lenta e l’offerta esposta è enorme.

Cosa dovrebbero fare i miner oggi

1. Usa formati di indirizzo moderni (bech32 bc1q o Taproot bc1p) per tutti i pagamenti da mining; evita i formati legacy dove possibile.
2. Non riutilizzare gli indirizzi. Generane uno nuovo per ogni pagamento — i wallet moderni lo fanno automaticamente.
3. Conserva in hardware wallet che si sono impegnati a supportare i tipi di indirizzo post-quantistici una volta attivati.
4. Segui BIP-360 / BIP-361 / Hourglass tramite Bitcoin Core e gli autori delle proposte.
5. Niente panico. La proof-of-work SHA-256 è al sicuro; le tue macchine continuano a funzionare invariate a prescindere da come si risolverà il dibattito sulle firme.

Considerazioni finali: i protocolli evolvono, i miner si adattano

La storia di Bitcoin è una sequenza di aggiornamenti che sembravano controversi sul momento e inevitabili col senno di poi. SegWit ha diviso la comunità, poi si è attivato e ha reso possibile Lightning. Taproot ha richiesto anni di dibattito, poi ha sbloccato scripting più ricco. Stratum V2 richiederà analogamente tempo per essere pienamente adottato — e poi ci chiederemo come abbiamo potuto tollerare il mining in chiaro non cifrato. La migrazione post-quantistica sarà più lunga e più contesa, ma gli incentivi economici sono allineati: proteggere il valore della rete, proteggere le monete degli utenti, e iniziare finché c’è ancora margine. Il tuo hardware di mining non deve cambiare per nulla di tutto questo. Le tue abitudini col wallet contano più del tuo algoritmo di hash: usa indirizzi moderni, non riutilizzarli, conserva in hardware wallet e resta informato.