DigiByte: perché la tua share non era un blocco

MultiShield di DigiByte ricalcola il target di mining SHA-256 ogni volta che arriva un blocco su uno qualsiasi dei suoi cinque algoritmi — in media ogni 15 secondi. La difficoltà di rete che vedi su un explorer, una dashboard o un report di mining è un’istantanea già superata. Una share che supera quel valore è un blocco valido solo se supera il target in vigore nel preciso secondo in cui raggiunge il pool. È il motivo più comune per cui un solo miner su DigiByte vede una share da record e non vince nulla.

Punti chiave

• Su DigiByte il target SHA-256 viene ricalcolato ogni volta che un blocco arriva su uno qualsiasi dei cinque algoritmi, non solo quando viene trovato un blocco SHA-256.
• In una finestra di 90 minuti, la difficoltà dei blocchi SHA-256 è andata da 418 milioni a 1,12 miliardi — un fattore 2,7.
• In un solo tratto di due minuti il target attivo è salito del 75%, da 748 milioni a 1,31 miliardi.
• Il valore di una share dipende dal target nel secondo in cui arriva. La stessa share può restare corta in un momento e vincere un minuto o due dopo.
• Nulla di tutto questo significa che un blocco sia andato perso. Una share sotto il target attivo non viene mai inviata come blocco, quindi non c’è nulla da rendere orfano, rifiutare o nascondere.

Perché la mia share ha superato la difficoltà di rete senza trovare un blocco?

Un solo miner su DigiByte ci ha inviato una segnalazione accurata e ben documentata. Il suo miner aveva prodotto una share di circa 997 milioni di difficoltà. Un report di mining generato circa un’ora dopo mostrava una difficoltà di rete di 531 milioni — il che rendeva la share quasi il doppio del target. Eppure nessun blocco era comparso. Aveva controllato l’API del pool, confermato che la share era stata ricevuta e accettata, e non aveva trovato traccia di rifiuti o di share stale. Secondo ogni numero che poteva vedere, avrebbe dovuto essere un blocco.

I numeri che poteva vedere erano reali. Erano anche i numeri sbagliati.

Abbiamo rintracciato la share nei log del pool. È arrivata tra le 06:26:31 e le 06:27:31 UTC del 4 ottobre 2026. In quel minuto la rete non richiedeva 531 milioni. Richiedeva da 1,13 a 1,21 miliardi. La share ha raggiunto tra l’82,7% e l’88,1% del necessario.

Il valore di 531 milioni era la difficoltà un’ora dopo, a picco ormai passato. E dalle 06:28:37 — uno o due minuti dopo l’arrivo della share — il target è sceso sotto i 997 milioni. La stessa share, un minuto o due più tardi, sarebbe stata un blocco.

Perché la difficoltà di DigiByte si muove così tanto?

DigiByte divide la produzione di blocchi tra cinque algoritmi di mining indipendenti — SHA-256, Scrypt, Skein, Qubit e Odocrypt — ognuno dei quali mina circa un blocco su cinque, ognuno con la propria difficoltà. La catena punta a un blocco ogni 15 secondi complessivi, quindi la corsia SHA-256 ha in media un blocco ogni 75 secondi.

La difficoltà di ciascuna corsia è gestita da MultiShield, l’estensione multi-algoritmo di DigiShield introdotta da DigiByte nel 2014. Mentre Bitcoin ricalcola una volta ogni 2.016 blocchi, MultiShield ricalcola la difficoltà a ogni singolo blocco.

Il dettaglio che sorprende i miner è che ricalcola tutte le corsie a ogni blocco, non solo quella che lo ha trovato. Lo dice esplicitamente il codice di consenso di DigiByte, in un commento sopra i parametri della difficoltà: la difficoltà di un algoritmo può scendere quando un algoritmo diverso risolve un blocco. Così il target SHA-256 non resta fermo tra un blocco SHA-256 e l’altro. Ogni blocco trovato su Scrypt, Skein, Qubit o Odocrypt lo sposta, e il risultato è un target che cambia circa ogni 15 secondi. Il nostro explainer su DigiByte copre l’algoritmo completo, letto direttamente dal codice di consenso.

Cosa ha fatto davvero il target in quel minuto?

Ogni volta che arriva un nuovo blocco, il pool costruisce un nuovo job di mining e registra il target che quel job deve rispettare. Questi sono i valori esatti registrati dai log del pool attorno alla share:

La share è arrivata tra le 06:26:31 e le 06:27:31, mentre il target era a 1.205.245.749 e poi a 1.130.849.418. Con 996.739.624 ha raggiunto tra l’82,7% e l’88,1% del necessario. Il target è sceso per la prima volta sotto la share alle 06:28:37.

Cosa abbia generato quell’onda diventa chiaro aggiungendo i blocchi SHA-256 che la catena ha effettivamente prodotto nella stessa finestra:

Tre blocchi SHA-256 sono arrivati in 99 secondi — uno ogni 33 secondi, contro un ritmo atteso di uno ogni 75. La corsia SHA-256 era nettamente avanti rispetto alle altre quattro, e MultiShield ne ha alzato la difficoltà in risposta, fino a un picco di 1,31 miliardi. Poi nessun blocco SHA-256 è arrivato per quattro minuti e ventiquattro secondi. Man mano che i blocchi arrivavano sugli altri algoritmi, il target è sceso, gradino dopo gradino. La share è arrivata subito dopo la cresta, mentre il target stava ancora scendendo.

I valori registrati sono la reale soglia della rete, non una stima. Ciascuno dei quattro blocchi SHA-256 qui sopra è stato minato esattamente al target che il pool aveva registrato pochi istanti prima, con corrispondenza all’unità. Tutti e quattro sono verificabili pubblicamente su qualsiasi explorer DigiByte.

Perché la difficoltà del report non corrispondeva al target?

Perché il report ha fotografato un momento di un’ora dopo, e su DigiByte un’ora è tanto tempo.

Qualsiasi valore di difficoltà tu guardi — su un explorer, una dashboard del pool, un report di mining o un calcolatore di redditività — è il valore nell’istante in cui è stato letto. Su Bitcoin quel valore vale per due settimane. Su DigiByte il target SHA-256 viene ricalcolato ogni volta che uno qualsiasi dei cinque algoritmi trova un blocco, quindi un valore preso alle 07:34 non dice quasi nulla su cosa fosse richiesto alle 06:27.

Nei novanta minuti attorno a questa share, la difficoltà dei blocchi SHA-256 sulla catena è andata da circa 418 milioni a 1,12 miliardi — un fattore 2,7. Una share da 997 milioni era ampiamente un blocco in fondo a quell’intervallo e ampiamente corta in cima.

C’è un’altra trappola. Gli explorer pubblicano la difficoltà di ogni blocco così come è stato minato — il valore che si applicava al vincitore. Non esiste alcun registro pubblico del target in vigore nei secondi tra un blocco e l’altro. Il target più alto del log qui sopra, 1,31 miliardi, non compare su nessun explorer, perché nessun blocco SHA-256 è stato minato mentre era in vigore. Eppure è proprio in momenti come quello che si consumano le occasioni mancate per poco.

Perché il target può saltare più del limite dell’8% di MultiShield?

Il nostro explainer su DigiByte osserva che MultiShield limita il suo retarget: la difficoltà può scendere fino al 16% in un passo ma salire al massimo dell’8%. Eppure dopo ciascuno dei tre blocchi SHA-256 veloci di questa finestra, il target è salito di oltre il 20% — del 22,9%, del 22,7% e del 21,7%.

I due fatti non sono in contraddizione, perché MultiShield sposta una corsia in due modi distinti. I limiti dell’8% e del 16% vincolano il retarget mediato della corsia stessa. A questo si aggiunge un aggiustamento per algoritmo del 4% che sposta la corsia a seconda che sia indietro o avanti rispetto alle altre quattro.

In questa finestra il secondo meccanismo ha prodotto un chiaro dente di sega. Ogni blocco su un altro algoritmo ha abbassato il target SHA-256 di circa il 4–5%. Ogni blocco SHA-256, arrivato mentre la corsia era già avanti, lo ha spinto di nuovo bruscamente in alto. Rileggi il log dei target qui sopra con questo in mente e lo schema è inconfondibile: tre grandi gradini in salita, ciascuno dopo un blocco SHA-256, poi una lunga scala in discesa.

In cosa è diverso dal Real-Time Targeting di eCash?

Il sintomo è identico — una share supera la difficoltà pubblicata e non vince nulla — ma il meccanismo no.

Su eCash il destino di una share dipende da quanto tempo fa è arrivato l’ultimo blocco; lo abbiamo documentato in dettaglio in eCash RTT: perché la tua share solo non era un blocco. Su DigiByte dipende da dove si trovava il target SHA-256 dopo il blocco più recente su qualsiasi algoritmo. Entrambi producono occasioni mancate per poco che, dal lato del miner, sembrano esattamente un blocco perso.

Succede anche su Bitcoin o sulle altre catene SHA-256?

Non in questa forma. Sulla maggior parte delle catene SHA-256 il target resta fisso per tutto un intervallo di blocco e cambia solo quando quella catena trova il blocco successivo.

Su Bitcoin e Bitcoin Cash, la difficoltà che consulti è quella che dovevi battere. Su DigiByte il target che ha deciso la tua share è esistito per pochi secondi e non è mai stato pubblicato da nessuna parte.

Il blocco è stato perso, reso orfano o nascosto?

No — perché non c’è mai stato un blocco.

Il pool registra un evento di soluzione del blocco ogni volta che una share raggiunge il target di rete del suo job. Per questa share non ce n’è stato nessuno. Il pool l’ha valutata rispetto al target attivo, l’ha trovata corta e l’ha accettata come una share ordinaria. Nessun blocco è stato assemblato, nessuna chiamata submitblock è stata fatta e nulla è stato inviato alla rete. Non c’era nulla da rendere orfano, rifiutare o perdere.

Su un pool non custodial questo si può verificare dall’esterno. L’indirizzo di pagamento del miner viene scritto nella transazione coinbase del template del blocco prima che inizi l’hashing, quindi ogni blocco reale compare on-chain a nome del miner, in modo permanente. Una share che non è mai diventata un blocco non lascia alcuna traccia di questo tipo — e un blocco reale non potrebbe essere nascosto, se fosse esistito.

Cosa dovrebbe fare davvero un solo miner su DigiByte?

Quasi nulla — ma leggi i tuoi numeri nel modo giusto.

• Tratta ogni valore di difficoltà come un’istantanea. Una best share sopra la difficoltà sulla tua dashboard o nel report non è la prova di un blocco perso. È la prova che il target era più alto quando è arrivata la tua share.
• La best share mostrata dal miner è calcolata in locale. I miner registrano la difficoltà di un hash nell’istante in cui lo trovano, prima che il pool abbia risposto, e spesso conservano un valore di sempre che non si azzera mai. Ti dice che il tuo hardware ha avuto un buon momento, non se quel momento era vincente.
• Lascia che il vardiff gestisca la difficoltà delle share. DigiByte ricalcola a ogni blocco, quindi una difficoltà fissa delle share adatta a un’ora può essere sbagliata l’ora dopo. La nostra guida al setup di DigiByte spiega la configurazione.
• Tieni bassa la latenza. Su una catena da 15 secondi, un server vicino accorcia l’intervallo tra la comparsa di un nuovo job e il momento in cui il tuo miner ci lavora.
• Controlla la coinbase, non il contatore. Per sapere se hai trovato un blocco, cerca il tuo indirizzo in una transazione coinbase on-chain.

Nulla di tutto questo cambia le tue probabilità nel lungo periodo. Le oscillazioni si compensano nel tempo, ed è per questo che una probabilità basata sulla difficoltà media — come nel nostro calcolatore delle probabilità solo — resta la base corretta per le aspettative. Le oscillazioni decidono solo quali singole occasioni mancate per poco diventano blocchi.

Fonti

• Parametri di consenso di DigiByte Core — la nota secondo cui la difficoltà viene aggiornata per ogni algoritmo a ogni blocco, e le costanti MultiShield nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 e nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, l’aggiustamento della difficoltà MultiShield (GetNextWorkRequiredV4)
• DigiByte (DGB) spiegato per i miner — il nostro profilo completo di MultiShield, letto direttamente dal codice di consenso
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman su MultiShield e il retarget a ogni blocco

I valori di target in questo articolo sono presi dai log del pool del 4 ottobre 2026, registrati ogni volta che veniva costruito un nuovo job di mining. Tutti e quattro i blocchi SHA-256 minati nella finestra — 24.323.739, 24.323.740, 24.323.742 e 24.323.752 — corrispondono esattamente al target che il pool aveva registrato pochi istanti prima di ciascuno, a conferma che i valori registrati sono la reale soglia della rete. Tutte le difficoltà dei blocchi citate sono verificabili pubblicamente su qualsiasi explorer DigiByte.