📖 Riassunto:

Un’anomalia nei timestamp dei blocchi Bitcoin – un blocco con orario precedente rispetto al blocco che lo precede nella catena – è lo spunto per esplorare come Bitcoin gestisce il tempo, quali sono le regole sui timestamp, quali piccoli “bug storici” esistono nel protocollo e perché esiste un potenziale attacco teorico chiamato Time Warp Attack. Un attacco che, almeno in teoria, potrebbe far crollare la difficoltà di mining e sconvolgere l’emissione di nuovi BTC ⚡.

🧱 Il “mistero” del blocco che arriva prima di quello precedente

L’episodio da cui parte l’analisi riguarda alcuni blocchi della blockchain Bitcoin:

• Il blocco 923.445 è stato minato alle 12:44:22.

• Il blocco 923.446 risulta minato alle 13:01 circa.

• Il blocco 923.447 riporta come orario 14:11.

• Il blocco 923.448, successivo nella catena, porta però l’orario 14:04, quindi prima del blocco 923.447.

A prima vista sembrerebbe che si sia “rotto” qualcosa: come può un blocco con numero più alto avere un timestamp precedente? Non dovrebbe essere sempre cronologicamente successivo?

In realtà questo comportamento è perfettamente compatibile con le regole di consenso di Bitcoin. Per capirlo, occorre ripassare:

• Che cos’è un blocco.

• Perché possono esistere blocchi vuoti.

• Come funziona il timestamp in una rete decentralizzata.

📦 Ripasso essenziale: che cos’è un blocco Bitcoin

Un blocco Bitcoin può essere immaginato come una “scatola virtuale” che contiene:

• Una serie di transazioni inviate dagli utenti.

• Alcune informazioni di intestazione (header), tra cui timestamp, riferimento al blocco precedente, nonce, ecc.

Gli utenti, quando spediscono una transazione, allegano una commissione (fee). Questa fee viene incassata dal miner che inserisce la transazione in un blocco e riesce a minarlo. Il guadagno del miner, tuttavia, non arriva solo dalle fee ma soprattutto dal sussidio in nuovi BTC (block subsidy), cioè dall’emissione di nuovi Bitcoin contenuti nella coinbase transaction del blocco.

Perché esistono blocchi vuoti?

Può sembrare controintuitivo, ma ogni tanto nella blockchain si osservano blocchi senza transazioni (eccetto la coinbase). Questo accade perché:

• Non appena un miner vede che è stato trovato un blocco, cerca immediatamente di minare quello successivo.

• Per massimizzare la probabilità di trovare il blocco successivo, inizia a lavorare sul nuovo header anche prima di aver raccolto e selezionato tutte le transazioni dal mempool.

• I tempi sono talmente rapidi che in alcuni casi il blocco viene trovato prima che l’algoritmo di selezione abbia riempito il blocco con transazioni.

Risultato: un blocco valido, ma vuoto, come nel caso del blocco 923.448.

⏱️ Tempo e decentralizzazione: perché gli orari dei blocchi non sono “perfetti”

In una rete completamente decentralizzata come Bitcoin, non può esistere un orologio centrale. Ogni nodo:

• Ha il proprio orario locale, sincronizzato più o meno bene con i server NTP o con l’orologio del sistema.

• Comunica con altri nodi che a loro volta hanno orari leggermente diversi (scarti di secondi o anche minuti).

Come funziona il timestamp di un blocco?

Il miner, quando propone un blocco, inserisce nel suo header un timestamp. Questo orario deve rispettare alcune regole piuttosto “larghe”, pensate proprio per evitare di dipendere da un singolo orologio centrale.

Regola 1 – Non più di 2 ore nel futuro ⏳

• Il timestamp di un blocco può essere al massimo 2 ore avanti rispetto all’orario mediano dei nodi con cui il miner è connesso.

• Se un nodo presenta un orario troppo sfasato (ad esempio oltre ~1,5 ore rispetto alla media), viene ignorato ai fini del calcolo.

Regola 2 – Deve essere più recente della mediana degli ultimi 11 blocchi 🧮

Per prevenire manipolazioni estreme, il timestamp di un nuovo blocco deve essere:

• maggiore della mediana dei timestamp degli ultimi 11 blocchi.

La mediana è il valore centrale di un insieme ordinato. Con 11 dati:

• Si ordinano i timestamp.

• Si scartano i 5 più bassi e i 5 più alti.

• Rimane il 6°: quello è la mediana.

Con queste regole, è perfettamente possibile che:

• Un blocco successivo abbia un timestamp leggermente precedente rispetto a quello che lo precede nella catena.

• Entrambi i blocchi rimangano comunque validi per il protocollo.

È quindi normale vedere situazioni come quella osservata con il blocco 923.448: numero più alto, orario leggermente precedente, ma regole di consenso rispettate.

🧠 Difficulty adjustment: l’orologio interno di Bitcoin

Bitcoin è progettato per avere, in media, un blocco ogni 10 minuti. Per mantenere questo ritmo, esiste il meccanismo del difficulty adjustment (aggiustamento della difficoltà).

Come funziona il difficulty adjustment?

• Ogni 2016 blocchi (un’“epoca”), la rete verifica quanto tempo è stato necessario per minarli.

• Teoricamente, 2016 blocchi × 10 minuti = 14 giorni.

• Se ci si è messi meno di 14 giorni ⇒ il mining è stato “troppo facile” ⇒ la difficoltà aumenta.

• Se ci si è messi più di 14 giorni ⇒ il mining è stato “troppo difficile” ⇒ la difficoltà diminuisce.

La difficoltà viene modificata agendo sul target (il valore che l’hash del blocco deve essere inferiore a), mantenendo così la media teorica dei 10 minuti.

🐞 Il piccolo “errore” di Satoshi: perché non sono esattamente 10 minuti

Nella progettazione del difficulty adjustment esiste un dettaglio tecnico spesso considerato una svista di Satoshi Nakamoto.

Il punto chiave

• Per ottenere una media accurata di 10 minuti tra blocchi, il conteggio temporale dovrebbe considerare gli intervalli tra i blocchi, non il numero di blocchi.

• Con 2016 blocchi ci sono in realtà 2015 intervalli tra il primo e l’ultimo blocco dell’epoca.

Esempio semplificato:

• Tra blocco 1 e blocco 2 c’è un solo intervallo di 10 minuti.

• Se si divide il tempo totale per il numero di blocchi anziché per il numero di intervalli, si introduce un leggero errore di stima.

Risultato pratico:

• Invece di avere esattamente 10:00 minuti di media, la teoria corretta porta a circa 10 minuti e 3 secondi.

È una discrepanza minuscola, ma esiste a livello puramente matematico. Nella pratica, comunque, la potenza di calcolo (hashrate) è sempre cresciuta nel tempo, portando spesso a un tempo medio reale inferiore ai 10 minuti e 3 secondi, intorno a ~9,5 minuti storici.

📊 Monitoring in tempo reale: l’esempio di Mempool.space

Strumenti come Mempool.space permettono di visualizzare in modo intuitivo lo stato attuale del mining:

• Blocchi mancanti alla fine dell’epoca (2016 blocchi).

• Tempo medio per blocco nell’epoca corrente (es. 10,1 minuti).

• Proiezione della data di fine epoca (es. “fra 7 giorni”).

• Stima della variazione di difficoltà (es. -1,25% se la rete sta impiegando più tempo del previsto).

Questi dati mostrano come il meccanismo di aggiustamento sia dinamico e reagisca ai cambiamenti di hashrate (ad esempio quando alcuni miner spengono le macchine per costi energetici troppo alti o cali di prezzo).

⚠️ Time Warp Attack: l’attacco teorico che “piega” il tempo di Bitcoin

Una volta capito che i timestamp non sono perfetti e che il difficulty adjustment si basa sul tempo trascorso tra il primo e l’ultimo blocco di un’epoca, emerge la possibilità di un attacco teorico: il Time Warp Attack.

Obiettivo dell’attacco 🎯

• Manipolare i timestamp dei blocchi in modo da far sembrare che la rete impieghi molto più tempo del dovuto per minare un’epoca.

• Indurre quindi il protocollo ad abbassare drasticamente la difficoltà.

• Arrivare a una condizione in cui un’entità con potenza di calcolo elevatissima possa minare blocchi a raffica (potenzialmente anche centinaia al secondo).

Le conseguenze sarebbero potenzialmente devastanti:

• Emissione accelerata di nuovi Bitcoin concentrata in poche mani.

• Nodi incapaci di seguire il ritmo dei blocchi.

• Incapacità pratica di includere le transazioni in modo ordinato ⇒ rete parzialmente inutilizzabile.

Prerequisito fondamentale 👉 Per portare avanti seriamente questo attacco, un soggetto dovrebbe controllare una quota di hashrate vicina o superiore al 51% della rete, da solo o tramite collusione di più mining pool.

📡 Distribuzione dell’hashrate e rischio di collusione

Nella realtà, l’hashrate di Bitcoin è distribuito tra diversi mining pool. Tuttavia, la concentrazione non è perfettamente simmetrica:

• Un pool può avere, per esempio, il 30% dell’hashrate.

• Un altro, il 18%.

• Insieme, superano già il 48%.

Una collusione ipotetica tra pochi grandi pool potrebbe avvicinarsi a quote pericolose. Non significa che ciò avverrà, ma mostra perché il Time Warp Attack venga considerato a livello accademico e tecnico, pur restando molto improbabile nella pratica.

🧩 Come funziona, nel dettaglio, il Time Warp Attack

L’idea alla base dell’attacco sfrutta il fatto che, al momento, il difficulty adjustment considera:

• Il tempo trascorso tra il primo blocco di un’epoca e l’ultimo blocco della stessa epoca.

Scenario “normale” (senza attacco)

• Bitcoin parte il 1° gennaio, ore 00:00 con il blocco X.

• Ogni blocco successivo viene minato circa ogni 10 minuti.

• Dopo 2016 blocchi, si arriva attorno al 14° giorno, sempre circa alla stessa ora.

• La rete misura il tempo tra il blocco di inizio epoca e quello di fine epoca e, se è vicino a 14 giorni, non modifica molto la difficoltà.

Scenario con attacco (schema concettuale)

Immaginare due “linee temporali”:

• Linea reale: ciò che accade nel mondo reale, con il tempo che scorre correttamente.

• Linea dell’attaccante: ciò che l’attaccante fa apparire alla rete manipolando i timestamp.

Passo 1 – Inizio in sincronizzazione

• All’inizio dell’epoca, l’attaccante si allinea con i tempi reali: il primo blocco di quell’epoca ha un timestamp corretto.

Passo 2 – Mining super veloce ma con orari “fissati”

• L’attaccante, grazie alla sua enorme potenza, mina blocchi molto più velocemente (nell’esempio estremo: uno al secondo).

• Per i primi 2015 blocchi dell’epoca, assegna timestamp che rimangono tutti molto vicini a una data nel passato (es. intorno al 14 gennaio, ore

  23:xx).

Passo 3 – L’ultimo blocco con timestamp “reale”

• L’ultimo blocco dell’epoca (2016°) viene minato con un timestamp attuale (es. 29 gennaio).

• Così facendo, il protocollo vede che tra il primo e l’ultimo blocco dell’epoca sono trascorsi, ad esempio, 14 giorni + 50 minuti invece di 14 giorni precisi.

Per la rete, quindi, sembra che ci si sia messo di più a minare l’epoca ⇒ la difficoltà viene leggermente abbassata.

Passo 4 – Ripetere e amplificare l’effetto

A questo punto, l’attaccante:

• Nel calcolo dell’epoca successiva sfrutta di nuovo le regole sui timestamp.

• Tiene schiacciati i timestamp dei primi 2015 blocchi verso una data nel passato (es. sempre il 14 gennaio, 23:xx), rimanendo comunque:

  • più avanti della mediana degli ultimi 11 blocchi.

  • entro le 2 ore rispetto all’orario dei nodi.

• Mina ancora una volta l’ultimo blocco con l’orario reale (es. 12 febbraio).

Con questo trucco, ogni volta che la rete misura il tempo tra inizio e fine epoca, risulta trascorso sempre più tempo del previsto. Di conseguenza:

• La difficoltà crolla progressivamente.

• L’attaccante può minare blocchi in modo sempre più rapido.

Nel limite teorico, con difficoltà molto bassa e hashrate enorme, si potrebbe arrivare a minare decine o centinaia di blocchi al secondo, con gli effetti catastrofici citati in precedenza.

🛡️ Perché è difficile (quasi impossibile) che accada davvero

Nonostante la teoria sia solida, il Time Warp Attack è considerato estremamente improbabile per diversi motivi:

• Serve un controllo enorme dell’hashrate (vicino al 51%).

• Un attacco del genere sarebbe altamente visibile a tutta la comunità di sviluppatori e operatori di nodi.

• La redditività economica per i miner coinvolti è dubbia, perché una rete sabotata ridurrebbe drasticamente il valore dei BTC ottenuti.

• La comunità potrebbe reagire con modifiche urgenti al protocollo (soft fork), invalidando la catena manipolata.

Per questi motivi, il Time Warp Attack è catalogato come vulnerabilità teorica, non come minaccia concreta a breve termine.

🧪 La proposta di fix: Great Consensus Cleanup Soft Fork

All’interno della community Bitcoin esiste già una proposta di miglioramento (BIP) nota come “The Great Consensus Cleanup” Soft Fork. Tra i vari obiettivi, questa include anche la mitigazione del Time Warp Attack.

Idea centrale del fix

• Invece di calcolare il tempo dell’epoca tra il primo e l’ultimo blocco dei 2016, si propone di considerare:

  • L’ultimo blocco dell’epoca precedente.

  • E l’ultimo blocco dell’epoca corrente.

In questo modo:

• L’attaccante non può più falsificare l’inizio dell’epoca “spingendo indietro” i primi 2015 blocchi.

• Il calcolo del tempo medio dipende da due punti che non possono essere sistematicamente manipolati rimanendo dentro le regole di consenso.

Il risultato è che il Time Warp Attack diventa impraticabile, pur mantenendo compatibilità con il comportamento corretto della rete.

💡 Curiosità e implicazioni didattiche

• Il comportamento “strano” dei timestamp (blocchi successivi con orari precedenti) è normale e non è un bug operativo.

• L’esistenza di piccoli “difetti storici” (come l’uso di 2016 blocchi invece di 2015 intervalli) mostra che anche Bitcoin è un sistema umano, perfezionabile nel tempo.

• L’analisi di bug teorici come il Time Warp Attack è fondamentale per la resilienza a lungo termine del protocollo.

👉 In sintesi:

L’anomalia dei blocchi con orario “invertito” non indica che Bitcoin sia rotto: è il risultato naturale di una gestione del tempo decentralizzata, che accetta range di timestamp piuttosto ampi pur di evitare qualsiasi autorità centrale.


Questa caratteristica, combinata con il meccanismo del difficulty adjustment, apre lo spazio a un attacco teorico – il Time Warp Attack – che sfrutta proprio la flessibilità dei timestamp per far apparire un’epoca più lunga del dovuto e forzare il crollo della difficoltà.


Nella pratica, però, servirebbe una concentrazione enorme di hashrate e una collusione rischiosa economicamente e reputazionalmente. La comunità è consapevole del problema e ha già proposto un soft fork di cleanup del consenso che cambierebbe il modo in cui viene calcolato il tempo delle epoche, neutralizzando l’attacco.


Il “caso” del blocco 923.448 diventa così un’ottima occasione per capire quanto Bitcoin sia al tempo stesso robusto, complesso e in continua evoluzione a livello di sicurezza e design protocollo 🧠⚡.