Vai al contenuto
Financial Context Wiki

Regolazione della difficoltà Bitcoin: target, retarget e limiti

Bitcoin ricalcola la soglia della prova di lavoro ogni 2.016 blocchi per riportare l'intervallo medio di lungo periodo verso dieci minuti. Target, codifica compatta, finestra temporale, limiti, regole di rete e risultati probabilistici vanno analizzati separatamente.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

La regolazione della difficoltà di Bitcoin è una regola di consenso deterministica che modifica periodicamente il massimo hash proof of work accettabile, detto target, per riportare l’intervallo medio dei blocchi nel lungo periodo verso dieci minuti al variare dell’hashrate attivo. Su mainnet il target resta normalmente fisso per 2.016 blocchi ed è ricalcolato per il periodo successivo. Ogni nodo validatore deriva lo stesso target obbligatorio dagli header precedenti; non viene votato dai miner né impostato da un explorer.

La prova di lavoro di un header è valida solo se il suo hash, interpretato come intero, è minore o uguale al target codificato nel campo nBits a 32 bit. Un target più piccolo ammette meno hash e richiede più tentativi attesi. Per convenzione, la difficoltà è un numero relativo inversamente proporzionale al target:

D = T₁ / T

Qui T è il target corrente e T₁ quello di riferimento per difficoltà 1. Target e difficoltà si muovono quindi in direzioni opposte. Nessuno dei due misura direttamente macchine, consumo energetico, identità dei miner o hashrate osservato.

Dieci minuti sono un valore atteso, non un orario. Tentativi di hash e arrivi dei blocchi sono casuali: due blocchi possono essere separati da pochi secondi oppure nessuno può apparire per un’ora anche con target e hashrate stabili. Il retarget è una retroazione ritardata su un periodo; riduce una deriva persistente della frequenza, ma non elimina la varianza a breve né risponde subito a uno shock dell’hashrate.

La regolazione influenza il ritmo temporale degli eventi basati sull’altezza, inclusi gli halving del sussidio, ma non definisce importi, intervallo di 210.000 blocchi o regola dell’offerta finale. Non seleziona da sola la catena canonica. La fork choice di Bitcoin confronta il chainwork cumulativo dopo aver validato header e blocchi; la difficoltà di un singolo blocco non è lavoro cumulativo.

Come analizzare il retarget

  1. Fissare rete e regole. Mainnet, testnet storica, Testnet4, signet e regtest non condividono ogni eccezione. Registra catena, regole software, altezza candidata e attivazione di retarget o blocchi speciali a difficoltà minima.
  2. Decodificare il target dichiarato. Espandi il nBits compatto dell’header candidato nel target T. Rifiuta target negativi, nulli, in overflow o sopra powLimit, poi richiedi che l’hash dell’header sia ≤ T.
  3. Individuare il confine. Su mainnet serve un nuovo target quando l’altezza candidata è divisibile per 2.016. Alle altre altezze il nBits del blocco precedente deve restare invariato.
  4. Scegliere la finestra temporale. Al confine mainnet, Bitcoin Core sottrae il timestamp del primo blocco del precedente periodo di 2.016 blocchi da quello dell’ultimo. Gli estremi contengono 2.016 blocchi ma solo 2.015 intervalli. La durata nominale resta 2,016 × 600 = 1,209,600 secondi.
  5. Limitare il tempo trascorso. Imposta t = clamp(t_actual, 302,400, 4,838,400) secondi, da un quarto a quattro volte i 14 giorni nominali. I timestamp degli header sono campi di consenso forniti dai miner e soggetti ad altri vincoli, non orari esatti di ricezione del nodo.
  6. Calcolare e codificare il nuovo target. Con le regole mainnet correnti, calcola con interi T_new = min(powLimit, T_old × t / 1,209,600), poi codifica in modo compatto il risultato in nBits. Divisione intera e arrotondamento compatto possono discostare leggermente i rapporti visualizzati dal calcolo decimale ideale.
  7. Interpretare probabilisticamente. In approssimazione, D_new / D_old = T_old / T_new. Confronta il retarget con la distribuzione dei tempi di blocco e un hashrate chiaramente indicato come stima; separalo da conclusioni su ricavi, chainwork, concentrazione e rischio di conferma.

La formula mainnet usa come T_old il target dell’ultimo blocco. Testnet4 è deliberatamente diversa: BIP 94 consente un blocco speciale a difficoltà minima dopo un timestamp sufficientemente ritardato, vieta l’eccezione al primo blocco del periodo e basa il retarget sulla difficoltà reale di tale blocco, evitando che un’eccezione temporanea contamini il periodo successivo. Regtest di norma disabilita il retarget. Una regola senza rete specificata è incompleta.

Esempi svolti

1. Periodo nominale invariato

Supponi T_old = 10 in unità arbitrarie di target e una durata misurata esattamente pari a 1,209,600 secondi. Il limite non cambia nulla:

T_new = 10 × 1,209,600 / 1,209,600 = 10

Il rapporto di difficoltà è 10 / 10 = 1, quindi la difficoltà idealizzata resta uguale. Non significa che ogni blocco abbia richiesto dieci minuti: intervalli casuali rapidi e lenti possono compensarsi.

2. Periodo rapido di 12 giorni

Supponi che i timestamp estremi distino 12 giorni. Poiché 12 è entro i limiti, il rapporto del target è 12 / 14 = 6/7. Il nuovo target è circa l’85,7143% del vecchio, mentre:

D_new / D_old ≈ 14 / 12 = 1.166667

La difficoltà idealizzata aumenta quindi di circa il 16,67%, non del 14,29%. Calo percentuale del target e aumento della difficoltà differiscono perché le grandezze sono reciproche.

3. Limite di quattro volte

Se i timestamp distano solo 1,75 giorni, il calcolo usa il minimo di 3,5 giorni. Il target può scendere a circa un quarto e la difficoltà salire a circa quattro volte in un retarget mainnet.

Se coprono 70 giorni, si usa il massimo di 56. Il target può salire fino a circa quattro volte e la difficoltà scendere a circa un quarto, salvo che powLimit limiti prima il target. “Limite di quattro volte” deve specificare se riguarda target o difficoltà e in quale direzione.

4. Shock dell’hashrate a metà periodo

Usiamo un’attesa semplificata: i primi 1.008 blocchi sono minati a un ritmo coerente con dieci minuti e richiedono circa sette giorni. Poi scompare il 30% dell’hashrate mentre il target resta fisso. Il 70% residuo avrebbe un intervallo atteso di 10 / 0.70 ≈ 14.286 minuti; gli ultimi 1.008 blocchi richiedono circa dieci giorni e l’intero periodo circa 17.

Ignorando estremi, casualità e arrotondamento compatto, il moltiplicatore del target è 17/14 ≈ 1.214286; quello della difficoltà è 14/17 ≈ 0.823529, un calo di circa il 17,65%. Non è il 30% completo perché lo shock ha interessato solo metà periodo. Se l’hashrate resta al 70%, dopo questa regolazione parziale i blocchi restano attesi più lenti di dieci minuti e il periodo seguente fornisce ulteriore retroazione.

Rischi ed errori di revisione

Errori di regole e calcolo

  • Chiamare difficoltà la soglia stessa invece di distinguere il target dalla sua misura relativa inversa.
  • Invertire la formula, facendo aumentare il target in un periodo rapido o la difficoltà in uno lento.
  • Trattare 2.016 blocchi come 2.016 intervalli temporali misurati; il calcolo mainnet corrente ne copre 2.015.
  • Dimenticare limiti di 3,5 e 56 giorni, powLimit, divisione intera o arrotondamento del nBits compatto.
  • Applicare un’affermazione mainnet a Testnet4, testnet storica, signet, regtest o altra catena proof of work.
  • Considerare la previsione di un explorer un input di consenso anziché una stima prima del blocco di confine.
  • Usare tempi locali di ricezione invece dei timestamp degli header consumati dal calcolo.
  • Confondere difficoltà corrente, lavoro per blocco, chainwork cumulativo o risultato della fork choice.

Misurazione e inferenza

  • Trattare l’hashrate stimato come inventario diretto delle macchine attive invece che inferenza da lavoro e arrivi casuali.
  • Estrapolare il retarget da una piccola parte del periodo, dove la normale varianza può dominare.
  • Leggere un aumento di difficoltà come prova di aumento di prezzo, ricavi miner, energia o decentralizzazione.
  • Leggere un calo come prova di guasto senza esaminare lavoro assoluto, concentrazione e durata.
  • Confrontare difficoltà tra catene senza normalizzare funzione hash, target di riferimento e regole di regolazione.
  • Descrivere dieci minuti come scadenza, garanzia di servizio o tempo fisso di conferma.
  • Inferire redditività senza ricompense, commissioni, disponibilità, condizioni pool, coperture, elettricità, finanziamento ed efficienza.

Sicurezza e operazioni

  • Trattare il retarget come protezione immediata da un afflusso o deflusso brusco di hashrate nel periodo corrente.
  • Supporre che una difficoltà minore aumenti la capacità dei blocchi o smaltisca subito un arretrato di transazioni.
  • Scegliere una politica di conferma dalla sola difficoltà ignorando lavoro cumulativo, capacità di riorganizzazione e valore.
  • Ignorare incentivi alla manipolazione dei timestamp e mitigazioni specifiche nel valutare i meccanismi.
  • Cambiare aritmetica di consenso, indicizzazione dei confini o codifica compatta senza vettori tra implementazioni e piano di attivazione.

Idee errate comuni

  • Ogni blocco Bitcoin richiede dieci minuti. Dieci minuti è la media obiettivo con hashrate corrispondente; ogni arrivo resta casuale.
  • I miner votano la prossima difficoltà. I nodi validatori calcolano indipendentemente il nBits consentito; un blocco con altro valore è invalido.
  • Un target più piccolo del 20% significa difficoltà più alta del 20%. La relazione è inversa: moltiplicatore target 0,8 implica difficoltà 1/0.8 = 1.25, cioè +25%.
  • Il retarget misura direttamente l’hashrate. Risponde alla produzione di blocchi con timestamp; ogni cifra è una stima con ipotesi di campionamento e tempo.
  • La difficoltà è la politica monetaria di Bitcoin. Il retarget stabilizza il ritmo temporale dell’emissione basata sull’altezza; regole separate definiscono sussidi e halving.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...