Bester Solo-Share, kein Block: eCash RTT

eCash Real-Time Targeting, bekannt als Heartbeat, ist eine Konsensregel, die das geforderte Mining-Target für etwa zwei Minuten nach jedem Block anhebt und es dann auf die veröffentlichte Schwierigkeit abklingen lässt. Ein Share, der die auf einem Explorer angezeigte Schwierigkeit schlägt, ist nur dann ein gültiger Block, wenn er nach diesem Abklingen eintrifft. Das ist der mit Abstand häufigste Grund, warum ein Solo-Miner auf XEC einen Rekord-Share sieht und nichts gewinnt.

Wichtigste Erkenntnisse

• eCash verlangt für etwa 115 Sekunden nach jedem Block eine höhere Schwierigkeit als die veröffentlichte, bei stabiler Kadenz.
• Die Anforderung beginnt astronomisch hoch und fällt mit der fünften Potenz der verstrichenen Zeit. Sie kann nie leichter sein als die Standardschwierigkeit.
• Explorer zeigen die Schwierigkeit jedes Blocks so, wie er gemint wurde — den Bodenwert. Es gibt keinen öffentlichen Feed der Live-Anforderung.
• Wir haben die offizielle Formel über 15 Messungen gegen die Logs eines Produktions-Nodes nachgerechnet: maximale Abweichung 0,002%.
• Die steile frühe Rampe, auf die Solo-Miner heute treffen, existiert ausschließlich wegen des Upgrades vom 15. November 2025, das ein Ein-Block-Filterfenster hinzufügte.

Warum hat mein Share die Netzwerkschwierigkeit geschlagen und keinen Block gefunden?

Ein Miner schrieb uns mit einer präzisen und völlig berechtigten Beschwerde. Er hatte einen eCash-Block mit einem Share von rund 8,0 Milliarden Schwierigkeit gegen eine veröffentlichte Netzwerkschwierigkeit von etwa 7,36 Milliarden gelöst. Stunden später verzeichnete sein Miner einen weit besseren Share — rund 11,87 Milliarden — und nichts geschah. Er prüfte jeden Block der Chain seitdem. Die veröffentlichte Schwierigkeit war die ganze Nacht zwischen 7,1 und 7,4 Milliarden geblieben. Nach Bitcoins Regeln war dieser Share ein Block.

Er hatte recht mit den Zahlen und unrecht mit der Regel. Auf eCash ist die Schwierigkeit, die ein Explorer veröffentlicht, nicht die Schwierigkeit, die du im Moment der Einreichung schlagen musst. Sie ist der Boden.

Sein Share von 11,87 Milliarden traf rund 100 Sekunden nach dem vorherigen Block ein — noch innerhalb der Rampe. In diesem Moment verlangte das Netzwerk 14,85 Milliarden, der Share war also etwa 80% dessen wert, was nötig gewesen wäre. Fünfzehn Sekunden später war die Rampe durchlaufen, die Anforderung fiel auf 7,33 Milliarden, und genau derselbe Share hätte gewonnen. Ihm fehlte keine Hashrate. Ihm fehlte eine Viertelminute.

Was ist eCash Real-Time Targeting?

Real-Time Targeting wurde mit dem Heartbeat-Upgrade am 15. November 2024 aktiviert. Das Problem, das es löst, ist typisch für kleinere SHA-256-Chains.

eCash teilt sich den Algorithmus mit Bitcoin und Bitcoin Cash, also wandert Hashrate zwischen ihnen und folgt der Rentabilität. Wenn die eCash-Schwierigkeit fällt, strömt externe Hashrate herein und mint mehrere Blöcke in schneller Folge — Turbo-Blöcke. Der Standard-Schwierigkeitsalgorithmus reagiert mit einer Anhebung; die Gast-Hashrate zieht weiter; die Chain bleibt mit hoher Schwierigkeit und einem Bruchteil der Hashrate zurück und produziert Blocklücken, die Stunden dauern können. Einzahlungen stocken. Bestätigungen werden unvorhersehbar.

Heartbeat greift die erste Hälfte dieses Zyklus an. Indem es Blöcke ungültig macht, die zu kurz nach ihrem Vorgänger gemint wurden, entfernt es den Anreiz für Burst-Mining, sodass der Basisalgorithmus gar nicht erst überkorrigiert. Das Design ist von Tom Hardings Forschung zu Real-Time Block Rate Targeting inspiriert.

Der Mechanismus funktioniert nur wegen Avalanche. Real-Time Targeting hängt von der eigenen Messung jedes Nodes ab, wann ein Block eintraf, und die ist naturgemäß subjektiv. Avalanche-Post-Konsens gleicht diese subjektiven Sichten zu einer einzigen Netzwerkentscheidung ab, ohne den Block-Header oder den Nakamoto-Konsens anzutasten.

Wie wird das eCash Real-Time Target berechnet?

Die Regel ist in Bitcoin ABC als Parking-Policy implementiert und nicht als Gültigkeitsregel. Der relevante Quellcode liegt in src/policy/block/rtt.cpp, und die Kernformel steht im Kommentar der Datei selbst:

target(t) = target(prev_block) * RTT_CONSTANT_FACTOR * t^(RTT_K - 1)

RTT_CONSTANT_FACTOR = RTT_K * gamma(1 + 1/RTT_K)^RTT_K / T^(RTT_K - 1)

RTT_K ist 6, das Target skaliert also mit der fünften Potenz der verstrichenen Zeit. T ist der Ziel-Abstand für das jeweilige Filterfenster. Die verstrichene Zeit wird ab dem Moment gemessen, in dem der Node jeden vorherigen Block-Header empfangen hat, nicht ab dem im Header eingetragenen Zeitstempel.

Die Formel wird über fünf Fenster gleichzeitig ausgewertet, und das strengste Ergebnis gewinnt:

Die Fensterlängen sind Primzahlen, wobei zwischen aufeinanderfolgenden Einträgen jeweils eine übersprungen wird. Der Quellcode erklärt warum: Es ist ein bewusster Versuch, Resonanzfrequenzen beim Verketten einer Filterreihe zu vermeiden. Die Reihe endet bei 17 Blöcken, weil weitere Fenster die Trennschärfe des Filters nicht mehr nennenswert verändern.

Zwei Eigenschaften sind für Miner wichtig. Es gilt das niedrigste Target über alle Fenster, also regiert die härteste Einschränkung. Und das Ergebnis ist gedeckelt: Das Real-Time Target ist nie höher — nie leichter — als das Standard-Target. Die Schwierigkeit kann nur nach oben gedrückt werden, nie nach unten.

Die Rekonstruktion der Konstanten aus gamma(1 + 1/6) = 0.9277193336 reproduziert alle fünf veröffentlichten Koeffizienten auf zehn signifikante Stellen.

Wie viel schwerer ist ein eCash-Block direkt nach dem vorherigen?

Das ist die Tabelle, die es sonst nirgends gibt, berechnet aus der offiziellen Formel bei stabiler Zehn-Minuten-Kadenz. Der Multiplikator wird auf die Schwierigkeit angewandt, die ein Explorer veröffentlichen würde.

Ein Block, der eine Sekunde nach seinem Vorgänger gefunden wird, bräuchte grob das Zwanzigmilliardenfache der veröffentlichten Schwierigkeit. Nach zehn Sekunden das Zweihunderttausendfache. Die Kurve ist brutal steil und hört dann einfach auf: Nach etwa 115 Sekunden entspricht die Anforderung exakt der veröffentlichten Schwierigkeit und bleibt dort.

Wenn die letzten Blöcke schneller als in zehn Minuten eintrafen, startet jedes Fenster von einer kürzeren verstrichenen Zeit, und die Rampe beginnt höher und dauert länger. Das ist kein Nebeneffekt. Das ist der Anti-Turbo-Block-Mechanismus bei der Arbeit.

Stimmt die Formel mit dem überein, was ein echter Node tatsächlich tut?

Wir haben es getestet. Unten stehen die Werte, die einer unserer eCash-Nodes in den zweieinhalb Minuten nach einem Block geloggt hat, daneben die Werte, die die veröffentlichte Formel allein aus den im selben Log sichtbaren Block-Ankunftszeiten vorhersagt.

Über alle fünfzehn geloggten Messungen betrug die maximale Abweichung 0,002%. Die veröffentlichte Formel ist keine Näherung dessen, was Nodes tun — sie ist exakt das, was sie tun.

Ein Detail lohnt sich hervorzuheben. Für die ersten 99 Sekunden war das Ein-Block-Fenster die bindende Einschränkung. Erst bei 109 Sekunden übernahm das Zwei-Block-Fenster, und 40 Sekunden später setzte die Standardschwierigkeit den Boden.

Was änderte sich am 15. November 2025?

Vor diesem Upgrade gab es vier Fenster, beginnend bei zwei Blöcken. Das Upgrade vom 15. November 2025 fügte das Ein-Block-Fenster mit seinem Abstand von 150 Sekunden hinzu.

Beide Konfigurationen bei stabiler Zehn-Minuten-Kadenz durch die Formel zu schicken, ergibt ein bemerkenswertes Resultat:

Bei normaler Kadenz erzeugte die Vier-Fenster-Konfiguration überhaupt keine Rampe. Sie griff nur, wenn Blöcke ohnehin schon zu schnell eintrafen — was ihr eng gefasster Zweck war. Die steile frühe Rampe, auf die ein Solo-Miner heute auf einer ansonsten gesunden Chain trifft, existiert ausschließlich wegen des im November 2025 hinzugefügten Ein-Block-Fensters.

Wenn du eCash vor diesem Datum solo gemint hast und das nie erlebt hast: Das ist der Grund.

Warum stimmt die von meinem Pool angezeigte Schwierigkeit nicht mit dem Explorer überein?

Weil es auf eCash unterschiedliche Zahlen sind, und die Mining-Software sagt das auch.

Bitcoin ABCs eCash-Solo-Mining-Software liest bei jedem getblocktemplate-Aufruf rtt.nexttarget, wandelt es in eine Schwierigkeit um und verwendet diesen Wert — nur für eCash — als die Netzwerkschwierigkeit, die sie meldet und loggt. Jede andere SHA-256-Chain nutzt stattdessen die Schwierigkeits-Bits aus dem Block-Header.

Dieser eine Zweig erklärt das Verhalten, das jeder eCash-Pool-Betreiber sieht: Nach dem Eintreffen eines Blocks ist die gemeldete Netzwerkschwierigkeit astronomisch hoch, fällt etwa zwei Minuten lang alle zehn Sekunden um eine Größenordnung und wird dann flach bei dem Wert, den ein Explorer später veröffentlichen wird.

Node-Betreiber haben eine zweite Möglichkeit: das Target lokal aus rtt.prevheadertime, rtt.prevbits und rtt.nodetime zu berechnen, die alle im Block-Template vorhanden sind. Beide Wege sind auf der eCash-Mining-Seite dokumentiert.

Was passiert mit einem Block, der das Real-Time Target verletzt?

Er wird geparkt, nicht abgelehnt. Der Node markiert ihn mit einer Policy-Verletzung namens policy-bad-rtt und stellt ihn beiseite, dann entscheidet das Avalanche-Polling, ob der Rest des Netzwerks zustimmt. Ist der Node in der Minderheit, dreht er seine Position. Der Block-Header bleibt dabei durchgehend unangetastet, und der Nakamoto-Konsens wird nicht verändert.

getchaintips auf einem eCash-Node zeigt diese neben der aktiven Chain, markiert mit status: parked. Auf einem unserer Nodes lieferte der Aufruf 262 geparkte Branch-Tips über die Blockhöhen 940.265 bis 960.666 — rund 20.400 Blöcke, also waren etwa 1,3% der Blöcke in diesem Bereich mindestens einmal geparkt.

Diese Zahl ist eine Obergrenze für Real-Time-Target-Verletzungen und keine Zählung davon. eCash parkt Blöcke aus mehreren Gründen, und Avalanche parkt außerdem die Verliererseite eines gewöhnlichen Fork-Rennens. Aber auf einer Chain, wo zwei konkurrierende Blöcke auf derselben Höhe selten sind, sagt dir eine Parked-Tip-Rate über einem Prozent, dass der Mechanismus aktiv ist und arbeitet, statt untätig zu sein.

Gilt das für Bitcoin, Bitcoin Cash oder die anderen SHA-256-Chains?

Nein. Unter den SHA-256-Chains ist dieses Verhalten einzigartig für eCash, weil es auf die Avalanche-Schicht angewiesen ist, um subjektives Timing abzugleichen.

Auf Bitcoin und Bitcoin Cash ist ein Share über der Netzwerkschwierigkeit ein Block, Punkt. Wenn du mehrere Chains minst und deine Best-Share-Werte zwischen ihnen vergleichst, ist die eCash-Spalte die einzige, in die das Timing einfließt. Unsere Aufschlüsselung der Solo-Mining-Chancen und das Netzwerk-Radar verwenden beide die veröffentlichte Schwierigkeit, was die richtige Grundlage für die langfristige Wahrscheinlichkeit ist — die Rampe mittelt sich über die Zeit heraus.

Wie groß ist die tote Zone für einen Solo-Miner?

Jeder Share, der landet, bevor die Rampe durchlaufen ist, ist verschwendet, egal wie gut er ist. Bei stabiler Kadenz:

Rund ein Fünftel jedes Blockintervalls ist für einen Share unbrauchbar, der die Schwierigkeit gerade eben überschreitet. Stärkere Shares durchlaufen die Rampe früher, weshalb ein wirklich gewaltiger Share fast nie verschwendet ist.

Das ändert deinen Erwartungswert in keiner Weise, auf die du reagieren könntest. Es ist bereits in der tatsächlichen Blockproduktion der Chain abgebildet und damit in der Schwierigkeit selbst. Nichts an deiner Miner-Konfiguration beeinflusst es.

Was sollte ein Solo-Miner tatsächlich dagegen tun?

Für die meisten lautet die ehrliche Antwort nichts — aber lies deine Zahlen richtig.

• Die Best-Difficulty-Anzeige deines Miners wird lokal berechnet, in dem Moment, in dem der Hash gefunden wird, bevor der Pool geantwortet hat. Sie hält den Wert fest, egal ob der Share jemals gültig gewesen wäre. Sie ist außerdem ein Allzeitwert, der nicht zurückgesetzt wird, wenn du einen Block findest.
• Ein bester Share aller Zeiten über der veröffentlichten Schwierigkeit ist auf eCash kein Beleg für einen verpassten oder gestohlenen Block. Wenn du bestätigen willst, dass ein Block existiert, sieh dir die Coinbase-Transaktion on-chain an. Bei einem nicht verwahrenden Pool wird deine Adresse vor Beginn des Hashens in den Coinbase geschrieben, sodass ein echter Block in deinem eigenen Namen sichtbar ist und ihn niemand verschieben kann.
• Wenn dich interessiert, wie nah du dran warst: Unser Artikel Best Share erklärt behandelt, wie man diese Zahlen liest, und der Chancen-Rechner übersetzt Hashrate in realistische Erwartungen. Die eCash-Pool-Seite listet die aktuelle Schwierigkeit und alle regionalen Endpunkte, der Konfigurationsgenerator baut die Stratum-Einstellungen, und Live-Daten zu Blöcken und Workern liegen im Pool-Dashboard.

Wenn du deinen eigenen eCash-Node fürs Solo-Mining betreibst, gibt es eine Konfigurationsoption, die zählt. Ein Node braucht 17 Blöcke an aufgezeichneten Header-Ankunftszeiten, bevor er das Real-Time Target berechnen kann. Bis er sie hat, kann er Templates mit zu niedriger Schwierigkeit bauen und seine Blöcke geparkt bekommen. persistrecentheaderstime=1 zu setzen, speichert diese Referenzzeiten auf Platte und lädt sie beim Neustart wieder, was die Lücke schließt.

Quellen

• eCash-Mining-Dokumentation — die RTT-Felder des Block-Templates, die Referenzimplementierung der Target-Berechnung und die veröffentlichten Filterkoeffizienten
• Heartbeat Upgrade: A Steady Pulse for eCash — die Begründung, das Switch-Mining-Problem und die Rolle des Avalanche-Post-Konsenses
• Bitcoin-ABC-Quellcode — src/policy/block/rtt.cpp, mit der Formel, den Fensterkonstanten und der Parking-Policy
• eCash-Solo-Mining-Software — wie das Real-Time Target auf eCash zur gemeldeten Netzwerkschwierigkeit wird

Die Prüfzahlen in diesem Artikel entstanden, indem die veröffentlichte Formel am 2. August 2026 gegen die Logs eines laufenden eCash-Nodes ausgewertet und die Ergebnisse Wert für Wert verglichen wurden.