Immagina di ricevere un pacco di lettere: normalmente lo apri e lo controlli in pochi secondi.
Ma ogni tanto arriva un pacco “trappola” che, pur sembrando normale, ti costringe a esaminare ogni foglio con una lente di ingrandimento per mezz’ora.
Nella rete Bitcoin succede qualcosa di simile con i blocchi lenti.
Un blocco Bitcoin è un insieme di transazioni che i miner creano e che tutti i nodi della rete devono verificare velocemente per confermare che sia valido.
In condizioni normali, questo controllo dura pochi millisecondi (meno di un decimo di secondo).
Con i blocchi lenti, invece, la verifica può richiedere decine di secondi o addirittura minuti. Il blocco è tecnicamente valido secondo le attuali regole di consenso, ma è stato progettato apposta per far “sudare” i computer.
È come un DoS (denial-of-service) nascosto: rallenta l’intera rete, crea ritardi e caos, e dà un vantaggio enorme a chi lo ha minato.
Perché esiste questo problema?
Bitcoin deve essere verificabile da chiunque, anche da un Raspberry Pi o da un vecchio server.
Per garantire la sicurezza, ogni nodo esegue controlli complessi su ogni transazione: firme digitali, script di spesa, regole di consistenza.
La maggior parte delle transazioni moderne (dopo SegWit) è ottimizzata e veloce. Ma le transazioni legacy (pre-SegWit, ancora presenti nella blockchain) permettono pattern di script che sfruttano un comportamento “quadratico” o semplicemente molto costoso dal punto di vista computazionale.
Un miner malevolo può creare una o due transazioni enormi (fino a quasi 1 MB di dimensione) piene di operazioni di firma (specialmente CHECKSIG e varianti) in modo da aumentare notevolmente il tempo di calcolo.
Il risultato?
Un blocco di dimensioni normali (sotto il limite di 1 MB o 4 MB con SegWit) che però richiede risorse enormi per essere validato.
La dimostrazione su Signet (aprile 2026)
Jameson Lopp e altri sviluppatori Bitcoin Core hanno eseguito demo pubbliche su Signet (la rete di test controllata).
Hanno minato e diffuso blocchi “avvelenati”:
- Dimensioni: circa 999,9 KB (quasi il massimo pre-SegWit).
- Numero di transazioni: solo 2.
- Tempo di validazione osservato: 48-51 secondi su hardware normale, fino a oltre un minuto su macchine più lente.
Nello screenshot da loro condiviso del client Bitcoin Core durante uno di questi test (tab “Slow Blocks”) si vedono chiaramente blocchi come il 299297 o il 299298: validazione a 50,469 s e 51,220 s, con solo 2 transazioni.
I blocchi normali invece vengono validati in 0,00x secondi.
Di questi blocchi è stato poi fatto un “reorg” (rimossi) per non inquinare la testnet, ma dimostrano che un miner con una piccola percentuale di hash rate potrebbe, in produzione, causare ritardi di propagazione, aumentare il tasso di blocchi orfani e rendere più difficile per i nodi mantenere la sincronizzazione.
Le conseguenze pratiche
- Nodi lenti o su hardware modesto (Raspberry Pi, VPS economiche) rischiano di rimanere indietro o di essere espulsi dalla rete.
- Propagazione rallentata: mentre un nodo impiega 50 secondi a validare, altri miner possono già lavorare sul blocco successivo, creando un vantaggio ingiusto per i pool più grandi.
- Attacco DoS: un miner può riempire la rete di questi blocchi e causare blackout parziali o fork temporanei.
- Centralizzazione: scoraggia l’esecuzione di nodi completi, riducendo la decentralizzazione di Bitcoin.
La soluzione: BIP 54 (Consensus Cleanup)
Il problema è noto da anni. La proposta BIP 54 (Great Consensus Cleanup) è un soft fork “di pulizia” che risolve quattro vulnerabilità storiche in un colpo solo, tra cui proprio i blocchi lenti.
Fix specifico per i blocchi lenti:
- Introduce un limite rigido di 2.500 operazioni di firma legacy (sigops) per transazione non-SegWit.
- Questo limite è molto conservativo: le transazioni normali ne usano pochissime.
- Risultato: il caso peggiore di validazione si riduce di circa 40 volte. I blocchi che oggi impiegano 50 secondi diventerebbero validabili in circa 1 secondo.
Il fix non invalida nessuna transazione esistente né “confisca” monete: basta suddividere le transazioni complesse in più parti (cosa già possibile e poco costosa).
Oltre ai blocchi lenti, BIP 54 risolve:
- L’attacco Timewarp (manipolazione della difficoltà).
- Vulnerabilità Merkle tree (transazioni da esattamente 64 byte che permettono falsi positivi).
- Duplicati di transazioni future (problema che si presenterebbe intorno al blocco 2.000.000).
Perché è importante attivarlo
Bitcoin è robusto, ma non perfetto.
Vulnerabilità come questa, se lasciate aperte, diventano armi potenti man mano che il valore della rete cresce.
La demo su Signet non è un allarme per spaventare, ma una chiamata all’azione: mostra concretamente che il problema è reale e risolvibile con un soft fork pulito e backward-compatible.
Attivare BIP 54 significa rendere Bitcoin più resistente, più accessibile (anche su hardware low-end) e più decentralizzato.
È una manutenzione necessaria, non una “cambiamento radicale”. I blocchi lenti non sono una teoria: sono già stati dimostrati in pubblico.
La domanda ora è semplice: possiamo convivere con questa vulnerabilità per evitare un soft fork, o la community potrà trovare un consenso per attivarlo?
Alla community la risposta.
