DigiByte: Warum dein Share kein Block war

DigiBytes MultiShield berechnet das SHA-256-Mining-Ziel jedes Mal neu, wenn auf einem seiner fünf Algorithmen ein Block eintrifft — im Schnitt alle 15 Sekunden. Die Netzwerkschwierigkeit, die du auf einem Explorer, einem Dashboard oder in einem Mining-Report siehst, ist eine bereits veraltete Momentaufnahme. Ein Share, der diesen Wert übertrifft, ist nur dann ein gültiger Block, wenn er das Ziel übertrifft, das genau in der Sekunde gilt, in der er den Pool erreicht. Das ist der häufigste Grund, warum ein Solo-Miner auf DigiByte einen Rekord-Share sieht und nichts gewinnt.

Das Wichtigste in Kürze

• Auf DigiByte wird das SHA-256-Ziel neu berechnet, sobald ein Block auf einem der fünf Algorithmen eintrifft, nicht nur, wenn ein SHA-256-Block gefunden wird.
• In einem 90-Minuten-Fenster lag die Schwierigkeit der SHA-256-Blöcke zwischen 418 Millionen und 1,12 Milliarden — ein Faktor von 2,7.
• Innerhalb eines einzigen Zwei-Minuten-Abschnitts stieg das aktive Ziel um 75%, von 748 Millionen auf 1,31 Milliarden.
• Der Wert eines Shares hängt vom Ziel in der Sekunde seines Eintreffens ab. Derselbe Share kann in einem Moment zu kurz greifen und ein, zwei Minuten später gewinnen.
• Nichts davon bedeutet, dass ein Block verloren ging. Ein Share unter dem aktiven Ziel wird nie als Block gesendet, also gibt es nichts zu verwaisen, abzulehnen oder zu verstecken.

Warum lag mein Share über der Netzwerkschwierigkeit und fand keinen Block?

Ein Solo-Miner auf DigiByte schickte uns einen sorgfältigen, gut recherchierten Bericht. Sein Miner hatte einen Share mit rund 997 Millionen Schwierigkeit erzeugt. Ein etwa eine Stunde später erstellter Mining-Report zeigte eine Netzwerkschwierigkeit von 531 Millionen — womit der Share fast doppelt so hoch wie das Ziel war. Trotzdem erschien kein Block. Er hatte die API des Pools geprüft, bestätigt, dass der Share empfangen und akzeptiert worden war, und keinen Hinweis auf eine Ablehnung oder einen veralteten Share gefunden. Nach jeder Zahl, die er sehen konnte, hätte es ein Block sein müssen.

Die Zahlen, die er sehen konnte, waren echt. Sie waren auch die falschen Zahlen.

Wir haben den Share in den Logs des Pools verfolgt. Er traf zwischen 06:26:31 und 06:27:31 UTC am 4. Oktober 2026 ein. In dieser Minute verlangte das Netzwerk nicht 531 Millionen. Es verlangte 1,13 bis 1,21 Milliarden. Der Share erreichte zwischen 82,7% und 88,1% des Nötigen.

Der Wert von 531 Millionen war die Schwierigkeit eine Stunde später, nachdem eine Spitze vorüber war. Und ab 06:28:37 — ein bis zwei Minuten nach dem Eintreffen des Shares — fiel das Ziel unter 997 Millionen. Derselbe Share, ein, zwei Minuten später, wäre ein Block gewesen.

Warum bewegt sich die Schwierigkeit von DigiByte so stark?

DigiByte verteilt die Blockproduktion auf fünf unabhängige Mining-Algorithmen — SHA-256, Scrypt, Skein, Qubit und Odocrypt — von denen jeder etwa einen von fünf Blöcken minet, jeder mit eigener Schwierigkeit. Die Chain zielt insgesamt auf einen Block alle 15 Sekunden, also kommt die SHA-256-Spur im Schnitt auf einen Block alle 75 Sekunden.

Die Schwierigkeit jeder Spur wird von MultiShield gesteuert, der Multi-Algorithmus-Erweiterung von DigiShield, die DigiByte 2014 eingeführt hat. Während Bitcoin einmal alle 2.016 Blöcke neu justiert, berechnet MultiShield die Schwierigkeit bei jedem einzelnen Block neu.

Das Detail, das Miner überrascht: Es berechnet alle Spuren bei jedem Block neu, nicht nur die Spur, die ihn gefunden hat. DigiBytes eigener Konsenscode sagt das ausdrücklich, in einem Kommentar über den Schwierigkeitsparametern: Die Schwierigkeit eines Algorithmus kann sinken, wenn ein anderer Algorithmus einen Block löst. Das SHA-256-Ziel steht zwischen zwei SHA-256-Blöcken also nicht still. Jeder Block auf Scrypt, Skein, Qubit oder Odocrypt verschiebt es ebenfalls, und das Ergebnis ist ein Ziel, das sich etwa alle 15 Sekunden ändert. Unser DigiByte-Explainer behandelt den vollständigen Algorithmus, direkt aus dem Konsenscode gelesen.

Was hat das Ziel in dieser Minute tatsächlich getan?

Jedes Mal, wenn ein neuer Block eintrifft, baut der Pool einen neuen Mining-Job und protokolliert das Ziel, das dieser Job erfüllen muss. Das sind die exakten Werte, die die Logs des Pools rund um den Share festhielten:

Der Share traf zwischen 06:26:31 und 06:27:31 ein, während das Ziel bei 1.205.245.749 und dann bei 1.130.849.418 stand. Mit 996.739.624 erreichte er zwischen 82,7% und 88,1% der Anforderung. Das Ziel fiel erstmals um 06:28:37 unter den Share.

Was diese Welle ausgelöst hat, wird klar, sobald man die SHA-256-Blöcke hinzunimmt, die die Chain im selben Fenster tatsächlich erzeugt hat:

Drei SHA-256-Blöcke trafen in 99 Sekunden ein — einer alle 33 Sekunden, gegenüber einem erwarteten Tempo von einem alle 75. Die SHA-256-Spur war den anderen vier weit voraus, und MultiShield hob ihre Schwierigkeit als Reaktion an, bis zu einem Höchstwert von 1,31 Milliarden. Dann kam vier Minuten und vierundzwanzig Sekunden lang kein SHA-256-Block. Während Blöcke auf den anderen Algorithmen eintrafen, sank das Ziel Schritt für Schritt wieder. Der Share traf kurz nach dem Kamm ein, als das Ziel noch davon abstieg.

Die protokollierten Werte sind die echte Anforderung des Netzwerks, keine Schätzung. Jeder der vier SHA-256-Blöcke oben wurde genau zu dem Ziel gemined, das der Pool kurz zuvor protokolliert hatte, auf die Einheit genau. Alle vier sind auf jedem DigiByte-Explorer öffentlich überprüfbar.

Warum stimmte die Schwierigkeit im Report nicht mit dem Ziel überein?

Weil der Report einen Moment eine Stunde später festhielt, und auf DigiByte ist eine Stunde eine lange Zeit.

Jeder Schwierigkeitswert, den du ansiehst — auf einem Explorer, einem Pool-Dashboard, in einem Mining-Report oder einem Rentabilitätsrechner — ist der Wert im Augenblick des Ablesens. Bei Bitcoin hält dieser Wert zwei Wochen. Bei DigiByte wird das SHA-256-Ziel jedes Mal neu berechnet, wenn einer der fünf Algorithmen einen Block findet, also sagt ein Wert von 07:34 fast nichts darüber, was um 06:27 verlangt war.

In den neunzig Minuten rund um diesen Share lag die Schwierigkeit der SHA-256-Blöcke auf der Chain zwischen etwa 418 Millionen und 1,12 Milliarden — ein Faktor von 2,7. Ein Share von 997 Millionen war am unteren Ende dieser Spanne klar ein Block und am oberen Ende klar zu kurz.

Es gibt eine weitere Falle. Explorer veröffentlichen die Schwierigkeit jedes Blocks so, wie er gemined wurde — den Wert, der für den Gewinner galt. Es gibt keine öffentliche Aufzeichnung des Ziels, das in den Sekunden zwischen den Blöcken galt. Das höchste Ziel im Log oben, 1,31 Milliarden, taucht auf keinem Explorer auf, weil kein SHA-256-Block gemined wurde, während es galt. Und doch ist es genau ein solcher Moment, in dem knappe Fehlschläge passieren.

Warum kann das Ziel stärker springen als die 8%-Grenze von MultiShield?

Unser DigiByte-Explainer hält fest, dass MultiShield sein Retarget begrenzt: Die Schwierigkeit kann pro Schritt um bis zu 16% fallen, aber höchstens um 8% steigen. Trotzdem stieg das Ziel nach jedem der drei schnellen SHA-256-Blöcke in diesem Fenster um mehr als 20% — um 22,9%, 22,7% und 21,7%.

Die beiden Tatsachen widersprechen sich nicht, weil MultiShield eine Spur auf zwei getrennte Arten verschiebt. Die Grenzen von 8% und 16% beschränken das gemittelte Retarget der Spur selbst. Hinzu kommt eine Anpassung pro Algorithmus von 4%, die die Spur danach verschiebt, ob sie den anderen vier hinterherhinkt oder voraus ist.

In diesem Fenster erzeugte der zweite Mechanismus ein deutliches Sägezahnmuster. Jeder Block auf einem anderen Algorithmus senkte das SHA-256-Ziel um etwa 4–5%. Jeder SHA-256-Block, der eintraf, während die Spur bereits voraus war, trieb es wieder steil nach oben. Lies das Ziel-Log oben mit diesem Gedanken, und das Muster ist unverkennbar: drei große Stufen nach oben, jede nach einem SHA-256-Block, dann eine lange Treppe nach unten.

Worin unterscheidet sich das vom Real-Time Targeting von eCash?

Das Symptom ist identisch — ein Share übertrifft die veröffentlichte Schwierigkeit und gewinnt nichts — der Mechanismus aber nicht.

Bei eCash hängt das Schicksal eines Shares davon ab, wie lange der letzte Block her ist; das haben wir ausführlich in eCash RTT: Warum dein Solo-Share kein Block war dokumentiert. Bei DigiByte hängt es davon ab, wo das SHA-256-Ziel nach dem jüngsten Block auf irgendeinem Algorithmus gerade stand. Beide erzeugen knappe Fehlschläge, die aus Sicht des Miners genau wie ein verpasster Block aussehen.

Passiert das auch bei Bitcoin oder den anderen SHA-256-Chains?

Nicht in dieser Form. Auf den meisten SHA-256-Chains bleibt das Ziel für die Dauer eines Blockintervalls fest und ändert sich erst, wenn diese Chain ihren nächsten Block findet.

Bei Bitcoin und Bitcoin Cash ist die Schwierigkeit, die du nachschlägst, die, die du übertreffen musstest. Bei DigiByte existierte das Ziel, das über deinen Share entschied, nur wenige Sekunden und wurde nirgends veröffentlicht.

Wurde der Block verloren, verwaist oder versteckt?

Nein — denn es gab nie einen Block.

Der Pool protokolliert ein Block-Lösungsereignis jedes Mal, wenn ein Share das Netzwerkziel seines Jobs erreicht. Für diesen Share gab es keines. Der Pool prüfte ihn gegen das aktive Ziel, fand ihn zu kurz und akzeptierte ihn als gewöhnlichen Share. Es wurde kein Block zusammengesetzt, kein submitblock-Aufruf gemacht und nichts an das Netzwerk gesendet. Es gab nichts zu verwaisen, abzulehnen oder zu verlieren.

Bei einem nicht verwahrenden Pool lässt sich das von außen prüfen. Die Auszahlungsadresse des Miners wird in die Coinbase-Transaktion der Blockvorlage geschrieben, bevor das Hashing beginnt, sodass jeder echte Block dauerhaft on-chain auf den Namen des Miners erscheint. Ein Share, der nie zum Block wurde, hinterlässt keine solche Spur — und ein echter Block ließe sich nicht verstecken, wenn es ihn gegeben hätte.

Was sollte ein Solo-Miner auf DigiByte tatsächlich tun?

Im Grunde nichts — aber lies deine Zahlen richtig.

• Behandle jeden Schwierigkeitswert als Momentaufnahme. Ein Best Share über der Schwierigkeit auf deinem Dashboard oder im Report ist kein Beweis für einen verpassten Block. Er beweist, dass das Ziel höher war, als dein Share eintraf.
• Die Best-Share-Anzeige wird lokal berechnet. Miner speichern die Schwierigkeit eines Hashes in dem Moment, in dem sie ihn finden, bevor der Pool geantwortet hat, und behalten oft einen Allzeitwert, der sich nie zurücksetzt. Er sagt dir, dass deine Hardware einen guten Moment hatte, nicht, ob dieser Moment ein Gewinner war.
• Lass die Vardiff die Share-Schwierigkeit steuern. DigiByte justiert bei jedem Block neu, also kann eine feste Share-Schwierigkeit, die zu einer Stunde passt, in der nächsten falsch sein. Unsere DigiByte-Einrichtungsanleitung behandelt die Konfiguration.
• Halte die Latenz niedrig. Auf einer 15-Sekunden-Chain verkürzt ein naher Server die Lücke zwischen dem Erscheinen eines neuen Jobs und dem Moment, in dem dein Miner daran arbeitet.
• Prüfe die Coinbase, nicht den Zähler. Um zu wissen, ob du einen Block gefunden hast, suche deine Adresse in einer Coinbase-Transaktion on-chain.

Nichts davon ändert deine langfristigen Chancen. Die Schwankungen gleichen sich mit der Zeit aus, weshalb eine Wahrscheinlichkeit auf Basis der durchschnittlichen Schwierigkeit — wie in unserem Solo-Wahrscheinlichkeitsrechner — die richtige Grundlage für Erwartungen bleibt. Die Schwankungen entscheiden nur, welche einzelnen knappen Fehlschläge zu Blöcken werden.

Quellen

• Konsensparameter von DigiByte Core — der Hinweis, dass die Schwierigkeit für jeden Algorithmus bei jedem Block aktualisiert wird, sowie die MultiShield-Konstanten nMaxAdjustUpV4 = 8, nMaxAdjustDownV4 = 16 und nLocalTargetAdjustment = 4
• DigiByte Core — pow.cpp, die MultiShield-Schwierigkeitsanpassung (GetNextWorkRequiredV4)
• DigiByte (DGB) für Miner erklärt — unser vollständiges Profil von MultiShield, direkt aus dem Konsenscode gelesen
• Measuring expected block timing for Difficulty Adjustment — Josiah Spackman über MultiShield und das Retarget bei jedem Block

Die Zielwerte in diesem Artikel stammen aus den Logs des Pools vom 4. Oktober 2026, protokolliert jedes Mal, wenn ein neuer Mining-Job gebaut wurde. Alle vier im Fenster geminten SHA-256-Blöcke — 24.323.739, 24.323.740, 24.323.742 und 24.323.752 — entsprechen exakt dem Ziel, das der Pool kurz vor jedem von ihnen protokolliert hatte, was bestätigt, dass die protokollierten Werte die echte Anforderung des Netzwerks sind. Alle genannten Blockschwierigkeiten sind auf jedem DigiByte-Explorer öffentlich überprüfbar.