Fünf Anpassungen der BLAKE2b Difficulty in elf Tagen

Die Betreiber der Informationsseite blake2bminer.com führen jede Anpassung mit Block, Zeitpunkt und Faktor auf. Sie betreiben dafür eine eigene mitvalidierende Node, und sie legen offen, dass ihnen BLAKE2b-Hardware gehört — das ist mehr Transparenz, als die meisten Fachmedien zum selben Thema aufbringen.

Der Wechsel selbst geschah am 30. August um 06:14 UTC bei Block 961.640. Bemerkenswert ist, wie er abgesichert wurde: Die Aktivierung verlangte laut der Statusseite der Kette eine Zeitungsschlagzeile im Coinbase-Eintrag des Blocks, "8-30 NYPost Deride And Conquer". Das ist dieselbe Geste wie im Genesis-Block von 2009 — nur dass sie hier technisch verhindern soll, dass jemand vorzeitig losrechnet.

Warum die erste Anpassung nach unten ging

Die erste Anpassung am 1. September senkte die Schwierigkeit um 41,3 Prozent. Das wirkt widersinnig, weil die Kette zu diesem Zeitpunkt längst wieder im Minutentakt Blöcke ausspuckte. Die Erklärung steckt im Messfenster: Eine Anpassung betrachtet die vergangenen 2.016 Blöcke, und in diesem Fenster lagen die drei Wochen Stillstand vom August, in denen die Abspaltung mit geerbter Difficulty ganze acht Blöcke zustande brachte. Gemessen wurde also überwiegend Stillstand. Wie dieser Mechanismus grundsätzlich arbeitet, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Ab der zweiten Anpassung kehrte sich das um. Zwischen dem 1. und dem 2. September entstanden 2.016 Blöcke in rund siebzehn Stunden — vorgesehen sind dafür zwei Wochen. Die Difficulty hätte sich etwa verzwanzigfachen müssen. Sie durfte es nicht.

Der Anschlag bei Faktor vier steht seit 2009 im Code

Bitcoin begrenzt jede Anpassung auf den Faktor vier nach oben und ein Viertel nach unten. Die Stelle dazu steht unverändert in src/pow.cpp, unter dem Kommentar "Limit adjustment step":

if (nActualTimespan < params.nPowTargetTimespan/4)
    nActualTimespan = params.nPowTargetTimespan/4;
if (nActualTimespan > params.nPowTargetTimespan*4)
    nActualTimespan = params.nPowTargetTimespan*4;

Diese Bremse ist kein Versehen, sondern Absicht: Sie soll verhindern, dass ein kurzer Ausreisser bei den Zeitstempeln die Kette in eine Richtung katapultiert, aus der sie nicht mehr herauskommt. Die BLAKE2b-Kette hat vorgeführt, was passiert, wenn eine Kette weit unterhalb ihrer tatsächlichen Rechenleistung startet: Sie braucht vier volle Anpassungen, um den Rückstand aufzuholen, und jede davon dauert so lange, wie 2.016 Blöcke eben dauern.

Erst die fünfte Anpassung am 12. September fiel mit dem Faktor 2,99 unter den Anschlag. Das ist die eigentliche Meldung dieser Woche, und sie klingt unspektakulärer als sie ist: Die Difficulty hat die Hashrate eingeholt. Ab jetzt misst die Kette, was tatsächlich an ihr rechnet, statt hinterherzulaufen.

191-mal schwerer, aber nur rund zehnmal mehr Rechenleistung

An dieser Stelle ist eine Unterscheidung wichtig, die in mehreren Berichten untergeht. Die Difficulty ist um das 191-Fache gestiegen, die Rechenleistung nicht. Die Miner-Seite beziffert die Hashrate der Kette kurz nach der Aktivierung auf rund 3 PH/s und Mitte September auf etwa 31 PH/s — ein Faktor von ungefähr zehn. Der Rest des Anstiegs ist schlicht Aufholjagd: Die Kette startete mit einer Difficulty, die viel zu niedrig war, und die vier Anpassungen am Anschlag haben diesen Abstand abgetragen.

Wer aus der Difficulty-Kurve also einen Ansturm von Minern herausliest, liest eine Korrektur. Verzehnfacht hat sich die Rechenleistung trotzdem, und das ist für eine drei Wochen alte Kette beachtlich.

31 PH/s gegen 910 EH/s

Beachtlich heisst nicht sicher. Der Dienst CoinWarz schätzt die Hashrate des SHA-256d-Netzwerks am 14. September auf 910 EH/s. Das sind 910.000 PH/s. Die BLAKE2b-Kette bringt es auf etwa ein Dreissigtausendstel davon.

Diese Zahl ist deshalb entscheidend, weil sie den Preis eines Angriffs bestimmt. Wer die Mehrheit der Rechenleistung auf einer Kette stellt, kann Transaktionen zurückdrehen. Auf der Hauptkette kostet das den Aufbau einer Industrie; auf der BLAKE2b-Kette kostet es eine Bestellung gebrauchter Siacoin-ASICs, denn die Hardware ist nicht exotisch, sondern seit Jahren im Handel. Genau das ist der Punkt, an dem Proof of Work seine Schutzwirkung aus der Höhe der aufgewendeten Arbeit zieht und nicht aus dem Algorithmus.

Auch im direkten Vergleich bleibt der Abstand gewaltig: Die Hauptkette stand am 14. September bei einer Difficulty von 127,45 Billionen, die Abspaltung bei 3,4 Milliarden. Die beiden Zahlen sind nicht unmittelbar vergleichbar, weil dahinter verschiedene Algorithmen stecken. Vergleichbar ist, was sie kosten — und das führt zurück auf die 910 EH/s.

Die finale Fassung ist da, der Pull Request bleibt ein Entwurf

Zwei offene Punkte aus unserem Beitrag vom 31. August lassen sich jetzt beantworten. Erstens: Bitcoin Knots 29.4.1 ist erschienen, allerdings am 2. September statt wie angekündigt am 1. Die Release Notes nennen den Algorithmuswechsel nüchtern "BLAKE2b proof-of-work algorithm (mitigates ongoing attack)" und führen daneben die befristete Blockgrenze von 800 kWU sowie mehrere behobene CVEs auf. Zweitens: Der von Luke Dashjr in Aussicht gestellte Rücksetzer auf Block 961.639 wurde nicht gebraucht. Die Kette läuft seit der Aktivierung durch.

Was sich dagegen nicht bewegt hat, ist Pull Request 359, der den Wechsel technisch trägt. Er steht weiterhin auf Draft, letzte Aktivität am 15. August, und die drei gemeldeten Prüfbefunde sind unverändert offen. Die Kette produziert also seit gut zwei Wochen Blöcke nach Regeln, deren Vorschlag formal noch nicht einmal zur Prüfung freigegeben ist. Wer das für eine Formalie hält, möge sich vor Augen führen, dass es bei einem Konsensbruch keine zweite Runde gibt.

Ein Pool, eine Börse — und eine Warnung vor dieser Börse

Für alle, die auf der Hauptkette minen, ändert das alles nichts: Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333, und die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der Abspaltung hat sich die Lage dagegen sortiert. Neben den Kleinstpools der ersten Tage gibt es inzwischen reguläre Angebote: B2Pool betreibt einen TIDES-Pool mit einem Prozent Gebühr und einer Mindestauszahlung von 10.000 Satoshi, dazu einen Solo-Zweig. Das Fachmedium Cryptolexicon beschreibt mit AlphaPool einen weiteren Anbieter mit PPLNS, 2,5 Prozent Gebühr und vier Relays in den USA, Europa und Singapur, der mit Antminer A3 und Goldshell SC ohne eigene Firmware arbeitet.

Auf der Handelsseite ist das Bild dünner. Am 2. September berichtete Bitcoin.com News von einer einzigen Börse, die BTCB2 listet, bei einem Tagesumsatz von rund 94.100 US-Dollar und einer Handelsspanne von 80 bis 176 Dollar an einem einzigen Vormittag. Bemerkenswert ist weniger der Kurs als die Begleitmusik: Eine Informationsseite aus dem Umfeld der Kette rät im selben Bericht ausdrücklich zur Vorsicht gegenüber genau dieser Börse. Kursangaben aus einem solchen Markt sagen nichts über einen Wert, und wir führen sie hier nur an, weil unsere Feststellung vom 31. August, es gebe für die Coins schlicht keinen Preis, damit überholt ist.

Die Seed-Masche ist zurück

Mit dem Handel kommt die Betrugswelle. Cryptolexicon weist darauf hin, dass im Umfeld der Kette die Behauptung kursiert, für den Erhalt von BTCB2 sei der Import der privaten Schlüssel oder der Seed-Phrase nötig. Das ist falsch. Es ist dieselbe Masche wie bei jeder Abspaltung seit 2017, und sie funktioniert, weil sie technisch halb plausibel klingt.

Der Sachverhalt dahinter: Beide Ketten teilen ihre Geschichte, dieselben Schlüssel gelten auf beiden. Genau deshalb öffnet eine Seed-Phrase, die ihr irgendwo eingebt, nicht nur die Fork-Coins, sondern auch eure echten Bitcoin. Wer eine Seed besitzt, auf der noch Guthaben liegt, bringt sie nirgendwo ein — nicht bei einem Pool, nicht bei einer Börse, nicht in einer Wallet, die Fork-Coins verspricht. Wer alte Bestände tatsächlich bewegen will, räumt zuerst alle echten Bitcoin auf eine neue, frisch erzeugte Wallet und fasst die alten Schlüssel erst danach an.

Für den Umgang mit den zugehörigen Phishing-Mails gilt unverändert, was wir zum BitBox-Phishing mit gültiger DKIM-Signatur geschrieben haben: Eine technisch korrekte Absenderprüfung sagt nichts darüber, ob der Inhalt stimmt.

Was die deutschsprachige Berichterstattung am 2. September schrieb

Am 2. September, also am Tag der zweiten Difficulty-Anpassung, meldete das Fachportal IT Boltwise, der Hardfork sei am 1. September gestartet und "nach Stunden zusammengebrochen", er habe kaum Rechenleistung angezogen. Beides lässt sich an der Kette nachzählen: Der Start war der 30. August, und statt eines Zusammenbruchs hat die Kette an genau jenem 2. September ihre zweite Anpassung am oberen Anschlag genommen.

Das ist kein Detail für Erbsenzähler. Wer eine Kette für tot erklärt, die produziert, unterschätzt sie zwangsläufig auch dort, wo Vorsicht angebracht wäre — etwa bei der Frage, wer auf ihr bezahlt wird und mit welchen Coins. Umgekehrt gilt dasselbe: Eine Kette, die Blöcke ausspuckt, ist deswegen nicht sicher. Beide Fehler entstehen aus derselben Bequemlichkeit, nämlich die Zahlen nicht nachzusehen, obwohl sie öffentlich sind.

Was das für euch heisst

Für den Bestand in eurer Wallet ändert sich nichts. Die Hauptkette läuft unverändert weiter, eure Schlüssel gelten dort wie vorher, und es gibt keinen Schritt, den ihr wegen dieser Abspaltung unternehmen müsstet.

• Nichts tun ist eine vollständige Antwort. Wer die Fork-Coins nicht will, muss dafür nichts einrichten, nichts importieren und nichts abholen.
• Die Seed bleibt, wo sie ist. Kein Werkzeug, kein Pool und keine Börse braucht sie, um euch etwas gutzuschreiben. Wer danach fragt, will das Guthaben auf der Hauptkette.
• Beim Mining zählt die Hardware, nicht der Name. SHA-256-Geräte können auf der BLAKE2b-Kette nicht rechnen. Wer dort minen will, braucht BLAKE2b-Hardware, und wer dafür Geld ausgibt, kauft sich in eine Kette mit einem Dreissigtausendstel der Absicherung ein.
• Beim Empfang von Zahlungen lohnt der Blick auf die Kette. Wer Bitcoin annimmt, sollte wissen, welche Node seine Zahlungseingänge bestätigt. Die Projektseite fordert Börsen ausdrücklich auf zu sagen, welche Kette sie gutschreiben — solange das nicht überall geschieht, ist die Frage berechtigt.

Fazit: Die Difficulty hat aufgeholt, die Sicherheit nicht

Die Kette hat den Test bestanden, der Ende August offen war. Sie produziert Blöcke, sie hat fünf Anpassungen durchlaufen, ihre Rechenleistung hat sich verzehnfacht, die finale Software ist erschienen, und der befürchtete Rücksetzer blieb aus. Das ist mehr, als ihr die meisten zugetraut haben, uns eingeschlossen.

Nur misst die Difficulty nicht, ob eine Kette Bestand hat, sondern nur, wie schwer der nächste Block zu finden ist. 31 PH/s gegen 910 EH/s, ein Pull Request im Entwurfsstadium, eine Börse mit Warnhinweis: Das ist der Stand nach elf Tagen Aufholjagd. Unsere Einschätzung vom 2. Juli bleibt deshalb unverändert. Eine Kette, deren gesamte Absicherung sich in zwei Wochen nachkaufen lässt, hat kein Difficulty-Problem gelöst, sondern nur ihr Blockproduktionsproblem — und das war nie das teure von beiden.

Die nächste Anpassung fällt bei Block 973.728 an. Wenn die Rechenleistung bleibt, dauert das diesmal die vorgesehenen zwei Wochen. Dann steht zum ersten Mal eine Zahl da, die nichts mehr aufholt, sondern etwas aussagt.

Quellen und weiterführende Links

• blake2bminer.com, Difficulty — alle fünf Anpassungen mit Block, Zeitpunkt und Faktor
• blake2bminer.com, Status — Aktivierung, Coinbase-Schlagzeile, Anschlag bei Faktor vier
• blake2bminer.com, Hashrate — Verlauf von rund 3 auf etwa 31 PH/s, Hardwarezahlen
• bitcoinknots/bitcoin, Release 29.4.1 und die zugehörigen Release Notes
• bitcoinknots/bitcoin, Pull Request 359 — Status Draft, letzte Aktivität 15.08.2026
• bitcoin/bitcoin, src/pow.cpp — die Begrenzung jeder Anpassung auf Faktor vier
• bitcoin-blake2b.org, FAQ — Datenlimits bis 1. September 2027, SIGHASH_UNIFIED, Hardware, Aufforderung an Börsen
• CoinWarz, Bitcoin Hashrate — Schätzung von 910 EH/s am 14.09.2026
• B2Pool — TIDES- und Solo-Mining auf der BLAKE2b-Kette
• Bitcoin.com News, 02.09.2026 — Listung, Umsatz und Warnhinweise
• Cryptolexicon — AlphaPool und die Seed-Falschbehauptung
• IT Boltwise, 02.09.2026 — der Bericht vom Zusammenbruch, gegen den sich die Zahlen halten lassen

The post BLAKE2b Difficulty: viermal am Anschlag, dann gebremst appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Der BLAKE2b-Hard-Fork kam zwei Tage früher als angekündigt

Den Anfang machte eine öffentliche Warnung. Am 29. August, 11:54 Uhr, schrieb Luke Dashjr: "PSA: Potential Bitcoin PoW change Sunday. SHA2 miners should stop mining Saturday." Bitcoin Knots 29.4.1rc4 werde am Tag darauf erscheinen und den letzten SHA-2-Block festschreiben; die Mitteilung wurde in mehreren Foren weitergereicht, weil sie ursprünglich auf X stand. Bemerkenswert ist die Wortwahl: Dashjr nannte den Vorgang eine mainnet rehearsal, also eine Generalprobe im Echtbetrieb. Wer schon einmal eine Generalprobe erlebt hat, bei der anschliessend niemand mehr zurückkonnte, weiss, wie viel Trost in dem Wort steckt.

Der Wechsel selbst erfolgte dann am 30. August um 06:14 UTC bei Block 961.640. Der letzte mit SHA-256d gefundene Block der Abspaltung trägt die Nummer 961.639 und stammt vom 28. August, 17:14 UTC — das lässt sich an einem öffentlichen Explorer nachsehen, der eine Bitcoin-Knots-Node ohne den neuen Algorithmus betreibt und deshalb bis heute genau dort stehen bleibt.

Acht Blöcke in drei Wochen: warum die Kette den Wechsel brauchte

Der Grund für die Eile steckt in der Difficulty. Als sich die Kette am 8. August bei Block 961.632 abspaltete, erbte sie den Schwierigkeitsgrad des Hauptnetzes von rund 127,5 Billionen — aber nur einen Bruchteil der Rechenleistung. Wie diese Anpassung funktioniert und warum sie nur alle 2.016 Blöcke greift, steht in unserem Grundlagenbeitrag Was ist die Mining Difficulty.

Die Zahlen des Explorers zeigen, was das praktisch bedeutet. Zwischen den Blöcken 961.633 und 961.639 lagen Abstände von 13.759 bis 475.772 Sekunden, also von knapp vier Stunden bis zu fünfeinhalb Tagen. Acht Blöcke in drei Wochen. Bis zur nächsten Anpassung bei Höhe 963.648 fehlten zum Zeitpunkt des Wechsels noch 2.009 Blöcke. Selbst mit der gesamten Hashrate des Bitcoin-Netzwerks wären das knapp vierzehn Tage gewesen — mit dem, was die Abspaltung tatsächlich hatte, Jahrzehnte.

Ein Proof-of-Work-Wechsel löst dieses Problem in einem Zug, weil er die Difficulty neu setzen darf. Genau das ist passiert.

Vom Stillstand in den Minutentakt

Die Wirkung war sofort sichtbar. Die Betreiber von blake2bminer.com, einer Informationsseite für Miner der neuen Kette, dokumentieren für den 30. August, 18:55 UTC, den Stand Block 961.877. Das sind 237 Blöcke in gut zwölf Stunden, also im Schnitt einer alle drei Minuten. Aus acht Blöcken in drei Wochen wurden 237 an einem halben Tag.

Das ist der Erfolg, den die Befürworter sich versprochen haben, und er ist real. Er hat nur einen Preis, den keine Difficulty-Anpassung wieder hereinholt: Die sechzehn Jahre aufgehäufte SHA-256-Arbeit, die eine Umschreibung der Bitcoin-Historie unbezahlbar macht, gelten auf der neuen Kette nicht mehr. Wer eine BLAKE2b-Kette angreifen will, muss nur mehr BLAKE2b-Leistung aufbringen als die paar Betreiber, die derzeit darauf rechnen. Der Unterschied zwischen einer Änderung, die alte Regeln verschärft, und einer, die eine neue Kette aufmacht, ist übrigens genau der zwischen Hardfork und Softfork — und diesmal ist es unmissverständlich ein Hardfork.

Was im neuen Block-Header steckt

Die technische Grundlage ist Pull Request 359 im Bitcoin-Knots-Repository, eröffnet von Dashjr am 15. August, 21 Commits. Er ersetzt nicht nur die Hashfunktion, sondern führt einen Block-Header in Version 2 ein. Die dort genannten Ziele sind:

• deutlich mehr Nonce-Raum, aufgeteilt in 128 Bit auf ASIC-Ebene, weitere 128 Bit je Maschine und 8 Bit darüber hinaus
• ein optionaler Schutz gegen Block-Withholding-Angriffe über einen XOR-Schlüssel
• vorbereitete Haken für Merged Mining, also für Seitenketten
• eine Festlegung der Transaktionszahl im Header, beschrieben als saubere Behebung von CVE-2017-12842
• Vorbereitung auf einen 64 Bit breiten Zeitstempel

Dazu kommen befristete Regeln. Die Projektseite der Kette nennt eine Obergrenze von 800.000 Gewichtseinheiten je Block — grob 300 Kilobyte — die bis zum 1. September 2027, 00:00 UTC gilt und danach automatisch entfällt. Das ist die Fortsetzung des ursprünglichen Streits mit anderen Mitteln: Es geht den Betreibern der Kette weiterhin darum, beliebige Daten aus der Kette herauszuhalten. Wer den Hintergrund dazu braucht, findet ihn bei uns unter Bitcoin Knots vs. Bitcoin Core.

Replay-Schutz gibt es nur, wenn ihr ihn anfordert

Der Punkt, der Nutzer am unmittelbarsten betrifft, steht in derselben FAQ: Die privaten Schlüssel bleiben auf beiden Ketten dieselben, und ein Replay-Schutz existiert nur als Option. Wer ihn will, muss das Signaturformat SIGHASH_UNIFIED verwenden. Ohne das kann eine Transaktion, die ihr auf einer Kette sendet, auf der anderen gültig sein.

Für den Umgang damit gilt unverändert, was der Node-Anbieter Start9 schon Mitte August zusammengetragen hat: Offene Lightning-Kanäle existieren nach einer Spaltung auf beiden Ketten, eure Node beobachtet aber nur eine davon. Und die alte Regel bleibt die wichtigste: Gebt eure Seed-Phrase niemals in ein Werkzeug ein, das euch Fork-Coins verspricht. Das war schon bei jedem früheren Fork der schnellste Weg, echte Bitcoin zu verlieren.

Mining für alle? Die Rechnung geht am ersten Tag nicht auf

In der Berichterstattung wurde BLAKE2b durchgehend als Rückkehr zum Mining mit gewöhnlicher Hardware verkauft: endlich wieder CPU und Grafikkarte statt Spezialchips. Das hält keinen Tag stand, und zwar nicht wegen einer Prognose, sondern wegen vorhandener Hardware. BLAKE2b ist der Algorithmus, mit dem seit Jahren Siacoin gemint wird, und es gibt dafür ASICs zu kaufen.

Die Miner-Seite zur neuen Kette beziffert eine RTX 3090 auf rund 5 GH/s und stellt daneben, dass eine Goldshell-SC-Box das Hundertfache schafft. CPUs bezeichnet sie als "not viable from the start". Die Projekt-FAQ selbst schreibt, ein Antminer A3 funktioniere "ab dem ersten Block". Die Kette hat also nicht die ASICs abgeschafft, sondern nur den Hersteller gewechselt — von den grossen SHA-256-Farmen zu einem Lager gebrauchter Siacoin-Geräte, das seit Jahren auf einen zweiten Frühling wartet. Das ist eine Dezentralisierung, die vor allem den Besitzern alter Hardware nützt.

Für alle, die weiterhin auf der Hauptkette minen, ändert das nichts. Der Bitaxe zeigt weiter auf den Pool eurer Wahl, bei uns auf stratum+tcp://blitzpool.yourdevice.ch:3333; die Übersicht dazu steht in der kleinen Bitcoin Solo Mining Bibel. Auf der BLAKE2b-Kette sind bislang eine Handvoll kleiner Pools aktiv, unter anderem SilentWave, PyBLOCK, Helios, PythonPool und TrueNorth — Namen, die vor drei Wochen niemand kannte.

Der Code, auf dem das läuft, ist offiziell noch ein Entwurf

Pull Request 359 trägt zum Zeitpunkt dieses Artikels weiterhin den Status Draft. In der Diskussion stehen drei von Prüfern gemeldete Befunde: Das Argument -powchangetime nimmt das dokumentierte Format time[:algo] nicht an, eine Assertion prüft 0x40 + 88 statt der offenbar richtigen 90, und die Testfunktion powhash bildet die tatsächliche Header-Konstruktion nicht ab. Die Kette läuft derweil auf einem Release-Kandidaten; die finale Fassung war für den 1. September angekündigt.

Das ist auch dann bemerkenswert, wenn ihr dem Vorhaben wohlwollend gegenübersteht. Ein Konsensbruch, der sich nicht rückgängig machen lässt, wurde hier ausgeliefert, bevor der zugehörige Vorschlag aus dem Entwurfsstadium heraus war.

Am Tag vor dem Fork verliess Luke Dashjr Ocean

Am 29. August, demselben Tag wie die Warnung an die Miner, veröffentlichten der Mining-Pool Ocean und Dashjr eine gemeinsame Mitteilung. Darin heisst es, er scheide im gegenseitigen Einvernehmen aus und lege die Ämter als Chairman, Chief Technology Officer und Verwaltungsrat nieder; das Unternehmen habe sämtliche Anteile zurückgekauft. Als Grund nennt die Mitteilung "the parties' different visions for the future of Bitcoin mining following the recent protocol developments". Dashjr startet demnach ein neues Vorhaben namens CONVOY.

Wer hier wen verlassen hat, sagt die Mitteilung nicht, und wir schreiben es deshalb auch nicht. Was sie sagt, reicht: Der Pool, der am 8. August den ersten signalisierenden Block gefunden hat, geht den Weg zur neuen Kette nicht mit — und der Rückkauf sämtlicher Anteile ist keine Formulierung für einen freundlichen Abschied.

Was in der Fachpresse steht und in den Quellen nicht

Zwei Angaben kursieren, die sich in den Primärquellen nicht wiederfinden. Erstens wird BLAKE2b mehrfach als quantenresistent beschrieben. In der Liste der Vorteile im Pull Request steht dieses Wort nicht, und die Projektseite begründet den Wechsel ebenfalls anders. Zweitens werden Zahlen zu hängenden Transaktionen und zur nötigen Hashrate genannt, die auf Testnetz-Beobachtungen einzelner Fachmedien zurückgehen; überprüfbar sind sie derzeit nicht. Beides ist im Auge zu behalten, keines davon taugt als Beleg.

Wie es weitergeht

Drei Termine bestimmen die nächsten Monate.

• 1. September 2026: Für diesen Tag ist die finale Fassung von Bitcoin Knots 29.4.1 angekündigt. Bis dahin läuft die Kette auf einem Release-Kandidaten, und Dashjr hatte einen Rücksetzer auf Block 961.639 in Aussicht gestellt, falls Fehler auftreten.
• Die erste Difficulty-Anpassung der neuen Kette: Sie zeigt, ob die Rechenleistung bleibt oder ob es sich um einen Startschub gehandelt hat. Bei dreiminütigen Blockabständen fällt sie in wenigen Tagen an — der eigentliche Belastungstest.
• 1. September 2027: An diesem Tag laufen die befristeten Datenlimits aus. Ob die Kette dann noch existiert, ist die interessantere Frage.

Offen bleibt zudem, ob eine Börse, ein Wallet-Anbieter oder ein Lightning-Dienst die Kette unterstützt. Bis heute hat sich keiner öffentlich dazu bekannt, und ohne das gibt es für die Coins auf der Abspaltung schlicht keinen Preis.

Fazit: Ein neuer Algorithmus ist keine wiederhergestellte Sicherheit

Der Wechsel hat getan, was er tun sollte. Die Kette produziert wieder Blöcke, die Difficulty-Falle ist aufgelöst, und das Vorhaben ist damit weiter, als es die meisten — uns eingeschlossen — Mitte August erwartet hätten. Wer daraus aber ableitet, das Projekt habe seine Probleme gelöst, verwechselt Blockproduktion mit Sicherheit.

Eine Kette ist so schwer angreifbar wie die Arbeit, die in ihr steckt. Diese Arbeit wurde am Sonntag auf null gesetzt und wird seither von einer Handvoll Betreiber mit gebrauchten Siacoin-ASICs neu aufgebaut. Der Code dazu ist ein Entwurf, der Replay-Schutz optional, der prominenteste Pool ausgestiegen und der Initiator gerade dabei, eine neue Firma zu gründen. Das mag alles noch werden. Aber es ist das Gegenteil dessen, was Proof of Work zum belastbaren Konsensmechanismus macht: aufgewendete Rechenleistung, die so teuer ist, dass ein Angriff sich nicht lohnt. Genau diesen Vorsprung hat die Kette am 30. August freiwillig aufgegeben. Unsere Einschätzung vom 2. Juli bleibt damit unverändert stehen.

Quellen und weiterführende Links

• bitcoinknots/bitcoin, Pull Request 359: Hardfork: New BLAKE2b proof-of-work algorithm
• btc-blake2b.org, FAQ der BLAKE2b-Kette — Datenlimits, SIGHASH_UNIFIED, Hardware
• btc-blake2b.org, Startseite des Projekts
• 110explorer.com — Explorer über eine Bitcoin-Knots-RDTS-Node, Blockabstände und Difficulty
• blake2bminer.com — Miner-Informationsseite mit Aktivierungszeitpunkt, Blockstand und Hardwarezahlen
• Joint Statement of OCEAN and Luke Dashjr, 29.08.2026
• Start9: Navigating the BIP-110 (RDTS) Activation — Replay- und Lightning-Risiken
• Weitergeleitete PSA von Luke Dashjr, 29.08.2026
• bip110.run — Chronik der Kettenspaltung vom 8. August

The post BLAKE2b-Hard-Fork ist aktiv: was jetzt wirklich läuft appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Was am 8. August wirklich passiert ist

Der letzte gemeinsame Block beider Ketten war 961.631. Bei Höhe 961.632 begann das Fenster, in dem BIP-110 von jedem Block eine Signalisierung auf Bit 4 verlangt. Blöcke ohne dieses Signal gelten für eine BIP-110-Node ab da als ungültig.

Die Hauptkette lieferte ihren Block 961.632 am 8. August um 19:35:55 UTC, gefunden von AntPool, mit 5.612 Transaktionen und einer Netzwerk-Difficulty von rund 127,5 Billionen. Das lässt sich in jedem Explorer nachsehen, etwa bei mempool.space. Dieser Block signalisierte nicht — die BIP-110-Nodes verwarfen ihn und blieben stehen, bis ein eigener Miner einen eigenen Block 961.632 fand. Ab diesem Moment gab es zwei Ketten.

Wie knapp die Sache war, sagt die Zahl, die BIP-Editor Mark Erhardt am 9. August auf der Entwickler-Mailingliste nannte: BIP-110 kam auf „just shy of 2.5% of blocks signaling readiness". Nötig gewesen wären 55 Prozent, also 1.109 von 2.016 Blöcken. Was ein Soft Fork und was ein Hard Fork ist und warum der Unterschied hier zählt, steht in Unterschied zwischen Hardfork und Softfork in der Blockchain.

Ein Detail, das in der Berichterstattung untergeht: 961.632 ist durch 2.016 teilbar — 2.016 mal 477 ergibt exakt diese Höhe. Die Abspaltung fiel also punktgenau auf eine Difficulty-Anpassung. Das war kein Zufall, sondern gewollt, und es hat für die Abspaltung die denkbar schlechteste Folge.

Die Difficulty-Falle: 2.016 Blöcke bis zur Anpassung

Eine abgespaltene Kette erbt die Schwierigkeit der Kette, von der sie sich trennt — hier also die vollen 127,5 Billionen, aufgestellt für ein Netz mit hunderten Exahash. Angepasst wird erst nach 2.016 eigenen Blöcken. Weil der Split exakt auf der Anpassungsgrenze lag, muss die BIP-110-Kette diese 2.016 Blöcke vollständig durchziehen, bevor ihre Difficulty auch nur ein einziges Mal fällt. Wer wissen will, wie diese Mechanik funktioniert: Was ist die Mining Difficulty.

Nach Angaben von Bitcoin.com stand die Abspaltung am 15. August bei Block 961.635, also vier Blöcken in sieben Tagen, gefunden vom Pool Roughnecks. Diese Zahl liess sich nicht gegen einen neutralen Explorer prüfen und ist als Medienangabe zu lesen. Rechnet sie trotzdem einmal durch: Bei vier Blöcken pro Woche braucht die Kette für 2.016 Blöcke rund 3.500 Tage — knapp zehn Jahre bis zur ersten Anpassung. Die kursierenden Schätzungen reichen von 350 Tagen bis 25 Jahren, je nach unterstellter Hashrate; die beobachtete Blockrate liegt am pessimistischen Ende.

Das ist kein Anlaufproblem, das sich mit Geduld löst, sondern ein Zustand, in dem eine Kette technisch existiert und wirtschaftlich nicht stattfindet — mit Folgen für jeden, der noch auf ihr sendet.

Ocean schickte 18 Stunden Hashrate auf die tote Kette

Der Mining-Pool Ocean räumte ein, dass ein Konfigurationsfehler Miner rund 18 Stunden lang auf der BIP-110-Kette arbeiten liess, obwohl diese den Endpunkt für die andere Kette gewählt hatten. Der Pool kündigte auf X rund 0,3 BTC Entschädigung an, auszuzahlen binnen 72 Stunden.

Als Lehrstück ist der Vorfall mehr wert als die Summe, denn er zeigt, wer bei einer Kettenspaltung tatsächlich entscheidet: nicht der Miner, sondern derjenige, der die Arbeitsaufträge verteilt — dasselbe Machtgefälle, das wir in Stratum V2 und die Coinbase-Hoheit beschrieben haben.

Der Plan: Proof of Work wechseln und die Miner feuern

Statt das Ergebnis anzunehmen, kündigten die Befürworter einen Ausweg an. Luke Dashjr, langjähriger Bitcoin-Entwickler und Mitautor auf der BIP-110-Seite, schrieb bereits am 5. August auf X: „If BIP110 doesn't pan out, the only option is a PoW change."

Ein Wechsel des Proof-of-Work-Algorithmus macht jeden vorhandenen Bitcoin-ASIC auf dieser Kette wertlos. Die Geräte rechnen SHA-256d in Hardware und können nichts anderes. Das ist kein Nebeneffekt, das ist der Zweck: Wer die Miner nicht überzeugen kann, schliesst sie aus.

„Bpedo": Wer hier wen angegriffen haben soll

Bemerkenswert ist, wie die Vorgänge seither beschrieben werden. Noch am Abend des 8. August schrieb Dashjr auf seinem X-Konto: „. @AntPoolofficial appears to be attacking Bitcoin. Hold tight everyone." Gemeint war der Pool, der wenige Stunden zuvor den regulären Block 961.632 gefunden hatte.

Am 12. August legte er unter der Überschrift „Facts" nach. Vier Punkte, sinngemäss: Am Samstag hätten „bad actors" einen strittigen Hard Fork versucht, „with the purpose of forcing users to distribute CSAM"; daraus sei eine neue „scamcoin with an airdrop" entstanden, die er „Bpedo" nennt. Die ehemaligen Bitcoin-Pools würden das Netzwerk angreifen, „to try to deceive the world into thinking Bpedo is 'the real Bitcoin'". Wer keine eigene Node betreibe, falle darauf herein; ein Upgrade auf „the latest release of Bitcoin Knots" bringe einen zurück „on the Bitcoin network". Und: „Community-led mitigations are in progress to overcome the ongoing attack" — erwartet zum 1. September.

Nüchtern betrachtet steht hier die Realität auf dem Kopf. Die Kette mit 97,5 Prozent der Hashrate hat keine Regel geändert — sie läuft unverändert weiter. Geändert hätte die Regeln der Vorschlag, der die nötige Zustimmung nicht bekam. Wer nichts tut, forkt nicht. Auch der CSAM-Vorwurf trägt die Last nicht, die ihm aufgeladen wird: Dahinter steht die seit Jahren bekannte Tatsache, dass sich beliebige Daten in Transaktionen einbetten lassen — ein Problem, das mit dem gescheiterten Fork weder entstanden noch verschwunden ist, und das kein Miner „erzwingt".

Die Zuspitzung hat einen praktischen Zweck: Wenn die Mehrheitskette ein Betrug ist, ist der Wechsel des Proof of Work keine Abspaltung mehr, sondern Notwehr.

BLAKE2b, ausgewürfelt auf Testnet4

Wie der neue Algorithmus bestimmt wurde, kündigte Dashjr am 11. August auf X im Detail an. Ab 14:00 UTC werde die Testnet4-Kette beobachtet. Dann: „The very next block found, look at the block hash. The last character will choose the new algorithm." Aus einer zuvor zusammengestellten, nach Eignung gewichteten Kandidatenliste sollte also das letzte Zeichen eines Testnetz-Blockhashes auswählen — ein Hexadezimalzeichen, sechzehn Möglichkeiten. Um Manipulation auszuschliessen, veröffentlichte er vorab den SHA256-Hash der Zuordnungstabelle: „You can prove I didn't rig it".

Einen Tag später stand das Ergebnis fest: BLAKE2b, mit einem geplanten Hard Fork zum 1. September 2026. Begründet wird die Wahl damit, dass BLAKE2b auf gewöhnlichen CPUs und GPUs laufe und die ASIC-Dominanz breche.

Die Vorab-Festlegung per Hash ist sauber gemacht, das sei ausdrücklich gesagt: Sie beweist, dass die Tabelle nachträglich nicht verändert wurde. Über die Frage, die zählt, beweist sie nichts. Denn welcher Hash-Algorithmus die Sicherheit eines Netzwerks im Milliardenbereich trägt, gehört in eine mehrjährige Prüfung mit Kryptografen, Referenzimplementierungen, Testnetzen und veröffentlichten Angriffsmodellen — nicht in ein Verfahren, dessen Ergebnis am letzten Zeichen eines Testnetz-Blockhashes hängt. Grosse Sorgfalt lag darauf, dass die Ziehung fair ist, und keine erkennbare darauf, ob überhaupt gezogen werden sollte. Manipulationssicher ausgewürfelt bleibt ausgewürfelt.

Wer Proof of Work tauscht, hat aufgehört, Bitcoin zu sein

Das eigentliche Problem liegt tiefer als die Frage, ob BLAKE2b ein guter Algorithmus ist. Bitcoins Sicherheit besteht nicht aus Regeln in einem Dokument, sondern aus über sechzehn Jahren aufgehäufter Rechenarbeit in SHA-256d. Diese Arbeit ist der Grund, warum sich die Kette nicht umschreiben lässt.

Ein Algorithmuswechsel setzt genau diesen Zähler auf null. Ab dem ersten BLAKE2b-Block sichert eine Kette, die eine sechzehnjährige Transaktionshistorie mit sich trägt, sich selbst mit der Rechenleistung eines Hobbynetzwerks. Wer sie umschreiben will, braucht dann keine Milliarden an Hardware mehr, sondern eine Handvoll Server. Die Befürworter wollen Bitcoin vor einem Angriff schützen und bauen dabei genau die Bedingung her, gegen die Proof of Work überhaupt schützt.

Der Streit um die BIP-Editoren

Parallel läuft ein zweiter Konflikt. Jon Atack beantragte am 9. August auf der Entwickler-Mailingliste, den Status von BIP-110 von „Deployed" auf „Closed" zu setzen, weil das Netzwerk den Fork abgelehnt habe. Widerspruch kam unter anderem von Greg Tonoski, der auf rund 18.000 Nodes verwies, die BIP-110 akzeptieren, und fragte, ob deren Guthaben damit zur Beschlagnahmung freigegeben sei. Sjors Provoost hielt dagegen, dass ein geschlossener BIP-Status niemandem etwas wegnimmt.

Am selben Tag beantragte Mark Erhardt in Pull Request 2248 die Abberufung von Luke Dashjr als BIP-Editor. Die Begründung nennt Interessenkonflikte bei einem Vorschlag, an dem er selbst beteiligt war, weniger als ein Prozent der Editor-Kommentare seit April 2024 und die vorzeitige Vergabe einer BIP-Nummer auf X, bevor der Vorschlag auf der Mailingliste diskutiert war. Die zugehörige Debatte steht in der Mailingliste.

Vollzogen wurde die Abberufung schnell. Bryan Bishop hielt am 10. August auf der Mailingliste fest: „The individual known as Luke Dashjr is no longer an authorized user in the BIP content repository." Damit ist der Schreibzugriff weg — die Rolle also faktisch beendet, keine 26 Stunden nach dem Antrag.

Formal hinkt die Dokumentation nach: Pull Request 2248 war am 17. August unverändert offen, und BIP 3, das die Zuständigen auflistet, führte ihn weiterhin auf. Wer die Lage prüfen will, schaut in beide Dokumente statt auf Schlagzeilen — die einen melden die Entfernung als abgeschlossen, die anderen zeigen sie noch nicht.

Was ihr tun könnt

Das Signalisierungsfenster ist vorbei, der angekündigte Hard Fork zum 1. September ist es nicht. Für die kommenden zwei Wochen gilt deshalb dasselbe wie im August:

• Prüft, welche Software eure Node fährt. Bitcoin Core und Bitcoin Knots vor der RDTS-Erweiterung sind konsensidentisch und folgen derselben Kette; die Unterschiede liegen in der Weiterleitungspolitik. Was das konkret heisst, steht in Bitcoin Knots vs. Bitcoin Core.
• Betreibt ihr Lightning-Kanäle, behaltet den 1. September im Auge. Ein offener Kanal über eine Kettenspaltung hinweg ist eine doppelte Haftung, weil der Gegenpart widerrufene Zustände auf der Kette veröffentlichen kann, die ihr nicht überwacht.
• Wenn ihr mint, klärt vorher, welche Kette euer Pool bedient und ob ihr das selbst umstellen könnt. Der Ocean-Vorfall zeigt, dass die Voreinstellung im Zweifel gegen euch läuft. Wer die Kettenwahl nicht abgeben will, betreibt Solo-Mining — etwa über blitzpool.yourdevice.ch oder einen anderen Solo-Pool, bei dem ihr die Node hinter dem Pool kennt.
• Verlasst euch bei einer Spaltung nicht auf eine Börse: Ob ihr auf einer, beiden oder keiner Kette gutgeschrieben werdet, entscheidet der Verwahrer nachträglich. Eigene Verwahrung und eine eigene Full Node sind der Unterschied zwischen Mitreden und Abwarten.

Wenn eure Node auf der Abspaltung hängt

Wer eine Knots-Version mit den RDTS-Regeln fährt, sieht die Hauptkette gar nicht: Die Node hat deren Block 961.632 als ungültig markiert und bleibt auf 961.631 stehen. Wer in diesem Zustand eine Transaktion gesendet hat, wartet womöglich unbegrenzt auf die Bestätigung — auf einer Kette, auf der alle paar Tage ein Block gefunden wird. Der Weg zurück, exemplarisch für eine Linux-Node:

# 1. Node stoppen
bitcoin-cli stop

# 2. Wallet-Verzeichnis sichern, bevor irgendetwas angefasst wird
cp -a ~/.bitcoin/wallets ~/wallets-backup-$(date +%F)

# 3. Binary austauschen: Bitcoin Core installieren oder eine
#    Knots-Version ohne die RDTS-Regeln. Danach Node starten.

# 4. Stand pruefen
bitcoin-cli getblockchaininfo | grep -e '"blocks"' -e bestblockhash

# 5. Haengt die Node weiter auf 961.631, den als ungueltig
#    markierten Hauptketten-Block wieder zulassen:
bitcoin-cli reconsiderblock \
  00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba

# 6. Bleibt sie stehen, den Blockindex neu aufbauen:
bitcoind -reindex-chainstate

Danach gleicht ihr Höhe und bestblockhash mit einem öffentlichen Explorer ab. Stimmen beide überein, seid ihr wieder auf der Kette, auf der der Rest des Netzes rechnet. Transaktionen, die auf der Abspaltung unbestätigt liegen geblieben sind, müsst ihr auf der Hauptkette neu senden.

Gebt eure Seed-Phrase nirgends ein, um Fork-Coins zu holen

Bei jeder Kettenspaltung tauchen Angebote auf, die versprechen, die Coins auf der neuen Kette „freizuschalten": eine Seite, eine App, ein Formular für eure Wiederherstellungsphrase. Tut das unter keinen Umständen, auch nicht, wenn das Angebot aus dem Umfeld des Forks selbst kommt.

Eure Seed-Phrase ist nicht der Schlüssel zu den Fork-Coins. Sie ist der Schlüssel zu allen euren Coins, auf jeder Kette, die aus demselben Ursprung hervorgegangen ist. Wer sie bekommt, räumt euer Guthaben auf der Hauptkette ab — und das ist echtes Geld, während Coins auf einer Kette mit vier Blöcken pro Woche und ohne Börsenanbindung praktisch nichts wert sind. Das Geschäft lautet also: alles riskieren für nichts.

Fazit: BIP-110 ist an der Arithmetik gescheitert, nicht an einer Verschwörung

BIP-110 hatte einen Mechanismus, der bei 55 Prozent Zustimmung greift, und bekam knapp 2,5. Danach braucht es keine Verschwörung mehr, nur eine Division. Die Kette, die daraus entstand, schafft vier Blöcke pro Woche und bräuchte in diesem Tempo ein Jahrzehnt bis zur ersten Difficulty-Anpassung. Das ist keine Unterdrückung durch eine Übermacht, sondern das vorhersehbare Ergebnis eines Plans, der die Hashrate für eine Formsache hielt.

Die Antwort darauf — einen ausgelosten Algorithmus einzuführen und die Mehrheit des Netzes zu Angreifern zu erklären — beendet die Diskussion, statt sie zu gewinnen. Eine Kette mit neuem Proof of Work ist kein gerettetes Bitcoin. Sie ist ein neues Projekt mit einer alten Transaktionshistorie und ohne die Arbeit, die diese Historie bisher geschützt hat. Es steht jedem frei, so etwas zu starten. Nur sollte es dann seinen eigenen Namen tragen.

Für alle anderen hat der August eine beruhigende Nachricht geliefert: Bitcoins Konsensregeln lassen sich nicht per Ankündigung ändern, auch nicht von langjährigen Entwicklern mit lauter Stimme. Das ist genau die Eigenschaft, wegen der sich das Ganze lohnt.

Quellen und weiterführende Links

• BIP-110: Reduced Data Temporary Softfork — Text des Vorschlags mit Aktivierungsparametern
• bitcoindev: BIP 110 – update status to closed — Debatte ab 9. August 2026
• bitcoindev: Motion to remove Luke Dashjr from BIP Editors
• bitcoin/bips Pull Request 2248: process – Remove Luke from BIP Editors
• BIP 3 — Liste der amtierenden BIP-Editoren
• mempool.space: Block 961.632 — Zeitstempel, Miner, Difficulty und Blockhash der Hauptkette
• Luke Dashjr am 5. August 2026 zum möglichen PoW-Wechsel
• Luke Dashjr am 11. August 2026 zum Auswahlverfahren über Testnet4
• Das X-Konto von Luke Dashjr — Fundstelle der Beiträge vom 8. und 12. August 2026 („attacking Bitcoin", „Facts"/„Bpedo")
• Ocean zur Entschädigung nach dem Konfigurationsfehler
• Start9: Navigating the BIP-110 (RDTS) Activation — Hinweise für Node- und Lightning-Betreiber
• bip110.run — Statusanzeige zu Signalisierung und Kettenspitzen
• Bitcoin.com: BIP-110 Breakaway Chain Faces a Long Fight to Survive — Fundstelle für Blockstand und Pool der Abspaltung

The post BIP-110 gescheitert: jetzt soll BLAKE2b es richten appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Die gute Nachricht: Die meisten ASIC Miner laufen nicht optimal ab Werk. Hersteller setzen konservative Standardeinstellungen, um zu garantieren, dass alle Chips - selbst die schwächsten aus der Produktion - stabil laufen. Das bedeutet aber auch: Euer spezifischer Chip könnte deutlich mehr leisten, effizienter arbeiten oder mit weniger Spannung auskommen. Jeder Chip ist anders, und genau hier liegt euer Potenzial!

Was euch in diesem Guide erwartet:

Lernt die Geheimnisse des Core Voltage & Frequency Tuning kennen - die beiden wichtigsten Parameter, die über Performance, Effizienz und Stabilität eurer Mining-Hardware entscheiden. Ob ihr nun:

• Probleme beheben wollt: Niedrige Hashrates, instabile Chips oder Hardware-Errors beseitigen
• Effizienz steigern möchtet: Bis zu 20-30% weniger Stromverbrauch bei minimalem Hashrate-Verlust (Undervolting)
• Maximum Performance anstrebt: Sicher übertakten für 5-15% mehr Hashrate (Overclocking)

Dieser umfassende Guide deckt alle drei Szenarien ab - von der Diagnose über die Optimierung bis hin zum sicheren Pushen eurer Hardware-Grenzen. Mit konkreten Beispielen, Schritt-für-Schritt-Anleitungen und technischem Hintergrundwissen ausgestattet, werdet ihr nach diesem Artikel genau wissen, wie ihr das Maximum aus euren Mining-Geräten herausholt!

Anfänger-Hinweis: Falls ihr neu in der Mining Welt seid, empfehlen wir euch, zunächst die Bitcoin Mining Bibel zu lesen, damit ihr die Grundlagen des Minings kennen lernt.

Quick Explain: Spannung & Frequenz

Core Voltage

Stellt euch dies als die Stromversorgung des Mining-Chips' Gehirn (dem Core) vor. Gemessen in Millivolt (mV), bestimmt es, wie viel elektrische Energie dem Chip für seine Berechnungen zur Verfügung steht.

Zu niedrige Spannung führt zu Instabilität ungültigen Shares ("Invalid Shares" oder "Summit-Fehler") und somit zu schlechterer Leistung; zu hohe Spannung erhöht die Wärmeerzeugung dramatisch und riskiert Beschädigungen.

Technischer Hintergrund: Der Chip führt im Grunde Berechnungen durch, bei denen Transistoren zwischen An- und Ausgängen schalten. Eine niedrigere Spannung führt dazu, dass diese Übergänge nicht schnell genug erfolgen oder fehlschlagen, besonders bei höheren Frequenzen. Die Spannung bestimmt auch den Schwellenwert, den die Transistoren erreichen müssen – unter diesem Punkt funktioniert der Chip nicht mehr zuverlässig.

Taktfrequenz

Gemessen in Megahertz (MHz), ist dies die Geschwindigkeit, mit der der Chip seine Hash-Berechnungen durchführt.

Höhere Frequenz = mehr Berechnungen pro Sekunde = potentiell höhere Hashrate, aber es benötigt auch mehr Stromzufuhr und erzeugt wesentlich mehr Wärme.

Technischer Kontext: Die Frequenz bestimmt, wie viele Male pro Sekunde die internen Logik-Gatter schalten. Bei SHA-256 (Bitcoin Mining) müssen Millionen von logischen Operationen pro Hash durchgeführt werden. Die Frequenz multipliziert sich direkt in der Hashrate-Berechnung.

Die tiefe Verbindung: Voltage × Taktfrequenz

Diese zwei Einstellungen sind nicht unabhängig.

Frequenz erhöhen erfordert Spannung: Wenn ihr die Frequenz erhöht, schalten die Transistoren schneller. Dies erfordert jedoch, dass die Spannung hoch genug ist, um diese schnelleren Übergänge zuverlässig zu treiben. Eine zu niedrige Spannung bei hoher Frequenz führt zu "Timing Violations" – der Chip kann seine Operationen nicht in der geforderten Zeit abschließen.

Spannung erhöhen kostet Energie & Wärme: Eine höhere Spannung bedeutet, dass mehr Strom durch die Transistoren fließt. Dies folgt dem Ohmschen Gesetz: P = V² × I / R. Da die Verlustleistung mit dem Quadrat der Spannung zunimmt (oder mit V × I), steigt die Wärmeerzeugung superlinear – eine kleine Spannungserhöhung kann zu einer großen Temperaturerhöhung führen.

Effizienzkurve (J/TH): Energieeffizienz wird in Joules per Terahash (J/TH) gemessen. Der optimale Punkt für die meisten ASIC-Chips liegt typischerweise im mittleren Spannungsbereich (nicht zu niedrig, nicht zu hoch) und bei einer Frequenz, die nicht zu weit über dem Factory Default liegt. Das "sweetspot" variiert stark je nach Chip und Batch.

Gibt es eine universelle "beste" Einstellung

Die kurze Antwort: Nein.

Die Werkseinstellungen (z.B. 1150mV / 550MHz für einen ASIC Chip wie den BM1370) sind lediglich sichere Startpunkte, die auf Durchschnittswerten über tausende von Chips basieren.

Warum Variationen existieren:

1. Silizium-Loterie (Silicon Binning): Auch Chips aus demselben Produktionslos zeigen geringfügige physikalische Variationen. Der Halbleiterprozess ist nicht perfekt – Dotierungskonzentrationen, Transistorgeometrie und andere Parameter weichen leicht ab. Das bedeutet, dass jeder Chip ein leicht unterschiedliches Optimal-Fenster für Spannung/Frequenz hat.
2. Thermal Interface & Wärmeableitung: Die Qualität der Wärmepaste, die Aufpressdruck und die Anbindung des Heatsinks variieren zwischen Chips. Ein Chip mit besserer thermischer Anbindung kann höhere Frequenzen bei gleicher Temperatur tolerieren.
3. Power Delivery: Die Qualität der Stromversorgung und die Stabilität eurer PSU beeinflussen, welche Spannungen zuverlässig geliefert werden können.
4. Umgebungstemperatur & Kühlung: Ein Miner in einer kalten Umgebung mit ausgezeichnetem Airflow wird anders OC-grenzen haben als einer in einem warmen Serverraum.

Wann ist dieser Leitfaden relevant

Dieser Guide ist für 3 Szenarien sinnvoll:

1. Performance-Optimierung (Overclocking – OC)

Sicher zusätzliche Performance heraus holen – natürlich mit Vorsicht!

2. Undervolting und Effizienz Tuning

Möchtet ihr die maximale Effizienz aus eurem Miner herausholen, dann seid ihr in diesen Abschnitt genau richtig. Wir senken die ASIC Spannung so ab, damit der Stromverbrauch sinkt, und die Effizienz des Geräts steigt. Das gute daran, es ist praktisch nicht gefährlich.

3. Troubleshooting Underperforming Chips

Wenn euer Miner-Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "HW Errors") zeigt, oder die Gesamthashrate konsistent unter Erwartungen liegt – dies deutet oft auf unzureichende Core Voltage für die aktuelle Frequenz hin.

Häufige Fehler:

• Low Hashrate: Der Chip hasht, sendet aber weniger als erwartete Shares
• Invalid Shares: Der Chip produziert ungültige Hashes (falsche Berechnungen)
• Hardware Errors (HW): Der Chip schlägt bei der Verarbeitung fehl

Vorbereitungen

Macht euch mit dem User Interface von AxeOS oder der NerdQ Geräte vertraut. Beide Geräte bieten eine saubere und übersichtliche Oberfläche an, um die Performance der Geräte bestens zu überwachen.

AxeOS:

NerdQ OS:

In den Dashboards habt ihr den Überblick zur Hashrate, dem Stromverbrauch, die Input Voltage des Netztteils, die ASIC Spannung in Volt, die ASIC Temperatur, die VRM/VR Temperatur, die Lüfterdrehzahl und die Lüfterdrehzahl in Prozent. Diese Angaben helfen euch, den aktuellen Stand des Gerätes einzuschätzen.

OC Modus freischalten

In AxeOS müsst ihr Einstellungen/Settings des Gerätes, und dort den OC Modus freischalten. Dazu muss am Ende des Browserlinks ein

?oc=

angehängt werden. Aus

http://192.168.5.30/#/settings

wird

http://192.168.5.30/#/settings?oc=

Danach zeigt sich ein gelber Banner mit einem Warnhinweis:

Auf den NerdQ Geräten könnt ihr das über einen einfach Button tun:

Danach könnt ihr die Frequenzen und die Spannungen freier auswählen und feiner abstimmen

Lüftersteuerung kennen lernen

Bitaxen und NerdQ Geräte verfügen über eine automatische Lüftersteuerung, welche nach einem Temperatur Target arbeitet. Heisst also, die Lüfter Geschwindigkeit passt sich automatisch an die ASIC Temperatur an. Erhöht ihr Frequenz und Spannung, steigt nicht unbedingt die Chip Temperatur, sondern die Lüfterdrehzahl erhöht sich, bis das Maximum von 100% erreicht ist.

Aus Sicherheitsgründen sollte ein Lüfter nicht bei 100% im automatischen Modus laufen, da hier keinerlei Reserven mehr bestehen, vor allem, wenn es im Raum wärmer werden sollte. Ein gutes Temperatur Target liegt bei 60°c. Optimalerweise dreht der Lüfter dabei bei ca 50% seiner maximalen Drehzahl

Die Einstellungen dazu findet ihr in den Settings von NerdQ oder AxeOS:

Bei Geräten mit besseren Kühlern kann man das Temperatur Target auch etwas absenken, sollte sich der Kühler zu fest langweilen, und der Lüfter mit sehr niedriger Drehzahl arbeiten. Generel kann man sagen, dass sich kühlere Chips besser übertakten lassen.

Temperatur Grenzen der Bitaxen und NerdQ Geräten

Wichtig zu wissen: die ASIC Chips sollten wenn möglich 70° nicht überschreiten. Aus Sicherheitsgründen fahren die meissten Home Miner bei über 70° herunter. Danach schaltet sich der Überhitzungsschutz ein. Dieser wird euch deutlich in den Einstellungen der Miner angezeigt. Deaktiviert den Überhitzungsschutz, und stellt die Standardwerte der Chips wieder ein (BM1370 = 525mhz bei 1.15v)

Teil 1: Der vorsichtige Weg zum Overclocking

⚠️ WARNUNG: Overclocking birgt Risiken

Bevor ihr weiterlest, müsst ihr diese Risiken verstehen und akzeptieren:

1. Fortgeschrittenes Wissen erforderlich

• Ihr benötigt ein solides Verständnis von Elektronik, eurer spezifischen Hardware und Kühlungsgrenzen
• Ein naives "einfach mehr Frequenz" Experiment wird mit hoher Wahrscheinlichkeit zu Problem und Instabilitäten führen

2. Hardware-Schadensrisiko

• Bleibende Schäden möglich: Falsche Einstellungen können euren ASIC-Chips oder Hashboards permanent beschädigen
• Point of No Return: Einige Schäden (z.B. gebrannte Transistoren) können nicht repariert werden
• Kettenschaden-Effekt: Ein überhitzter Chip kann umliegende Komponenten beschädigen

3. Wärme & Effizienz Herausforderungen

• Overclocking kann die Wärmeerzeugung dramatisch erhöhen – potentiell um 50% oder mehr
• Power Consumption erhöht sich (gemessen in Watts): Dies ist nicht linear. Eine 10% Frequenzerhöhung + Spannungserhöhung könnte zu 20–30% mehr Stromverbrauch führen
• Effizienz sinkt (gemessen in J/TH – Joules pro Terahash): Wenn ihr 40% mehr Strom für 15% mehr Hashrate braucht, wurde eure Effizienz durch OC unverhältnismässig verschlechtert
• Lebensdauer der Hardware kann drastisch sinken (halbe Lebensdauer ist nicht selten bei aggressivem OC)

4. Kühlung ist existentiell

• Ihr solltet eine ausreichende Kühlung haben, bevor ihr OC versucht:
  • Niedrige Umgebungstemperaturen (idealerweise < 25°C)
  • optimierter Airflow, guter Lüfter
  • Hochwertige Heatsinks oder sogar Flüssigkeitskühlung für extreme OC
• Überhitzung ist der schnellste Weg zum Versagen. Ein überheizter Chip wird zum "Brick".

5. Garantieverlust

Overclocking führt zum Garantieverlust eures Gerätes. Wenn er durchbrennt, wars das. Es gibt sicherlich keinen Ersatz vom Verkäufer!

Wenn ihr die Risiken akzeptiert: Die methodische OC-Prozedur

Voraussetzungen

Bevor ihr ein einziges MHz erhöht, überprüft diese Bedingungen:

1. Baseline Stabilität

• Euer Miner läuft 100% stabil mit den aktuellen Einstellungen
• Keine unerklärten Fehler oder spontanen Reboots über Stunden hinweg
• Alle Chips senden konsistent gültige Shares und die erwartete Hashrate wird auch tatsächlich erreicht

2. Temperatur im grünen Bereich

• ASIC Core Temp liegt stabil bei ~60°C oder eurem eingestelltem Target
• VRM (Voltage Regulator) liegt unter ~70°C
• Der Lüfter dreht bei 50% seiner maximalen Drehzahl im automatischen Modus
• Diese "Sicherheitsmargen" geben euch Platz für die Wärmesteigerung durch OC

3. Stromversorgung mit Headroom

• Euer Netzteil hat 30% Kopfraum über dem aktuellen Stromverbrauch
  • Beispiel: Wenn euer Miner aktuell 75W zieht, sollte euer Netzteil mind. 110W haben
  • Grund: Netzteile die am Limit arbeiten PSUs werden instabil, liefern niedrigere Spannung, können ausfallen
• Überprüft die PSU-Kabelqualität (keine beschädigten, frayed oder überheizten Kabel)

Eine Bitaxe mit aussreichender Kühlung und genügend Spielraum:

Die Temperatur liegt bei 60°, der Lüfter ist erst bei 42%

Overclocking Schritt für Schritt durchführen

Schritt 1: Kleine Frequenzerhöhung

Erhöht die Frequenz für der Chips um +10 MHz (z.B. von 550 auf 560MHz).

Warum +10 MHz?

• Groß genug, um messbar zu sein (nicht in dem Rauschen der Mess-Variabilität)
• Klein genug, um bei Instabilität schnell zu erkennen
• Standard in der Mining-Community

Schritt 2: Speichern & Neustart

In neueren Version von AxeOS und NerdQ OS muss das Gerät nicht neugestartet werden.

Schritt 3: Kritisches Monitoring (15–30+ Minuten)

Das ist der wichtigste Schritt. Geht ins Dashboard und beobachtet intensiv:

3a) Stabilität & Submissions

• Sind alle Shares gültig? Keine neuen "Invalid Shares" oder "HW Errors"?
• Ist die beobachtete Hashrate nahe der erwarteten Hashrate für die neue Frequenz?
  • Die Firmware des Miners oder der Pool sollte euch die erwartete Rate für 560MHz anzeigen
  • Wenn eure beobachtete Hashrate sinkt oder unter der Erwartung liegt, ist das ein Zeichen, dass zu wenig Spannung am Chip anliegt
• Konsistenz: Ist die Hashrate stabil oder "flattert" sie?

3b) Temperatur-Überwachung

• Temperatur-Steigerung: Wieviel ist die Drehzahl des Lüfters, oder die Temperatur des ASICS und der VRMs durch die +10MHz Frequenzerhöhung gestiegen?

3c) Hardware Errors & Log-Überwachung

• Tauchen neue Fehler auf? Spezifisch:
  • nonce_range_err – kann auf Timing Violations hindeuten
  • device_hw_errors – Chip-Fehler
  • shares_stale – seltener, aber kann auf "zu lange Berechnung" hinweisen

Wo beobachten:

• Miner Web-Interface (Live Hashrate, Temperature, Error Counter)
• Pool Dashboard: Ist die Accepted vs. Rejected Rate stabil?

Das Dashboard zeigt eine stabile Temperatur, der Lüfter ist nicht ausgereizt, die VRMs bleiben schön kühl.

Schritt 4: Stabil? Wiederholt die Frequenzerhöhung

Falls alles ok ist nach 30 Minuten Monitoring:

1. Erhöht die Frequenz um weitere +10 MHz (z.B. 560 → 570MHz)
2. Speichert oder Startet neu bei älteren Versionen
3. Geht zurück zu Schritt 3 – monitort erneut

Typisches OC-Szenario:

550MHz (Baseline, stabil) 
→ 560MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 570MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 580MHz (+10) - stabil, +0°C, 0 Fehler, Temperatur OK ✓
→ 590MHz (+10) - stabil, +1°C, 0 Fehler, Temperatur OK ✓
→ 600MHz (+10) - stabil, +2°C, 0 Fehler, Temperatur OK ✓
→ a) 610MHz (+10) - instabil (Fehler oder Hashrate sinkt), Temperatur OK, x
→ b) 610MHz (+10) - stabil, Temperatur zu hoch, x

a) ihr müsst die ASIC Spannung um 10mv erhöhen und nochmals testen
b) ihr müsst für eine bessere Kühlung sorgen

Schritt 5: Instabilität erkennen und beheben

Wenn ihr nach 30 Minuten bei der neuen Frequenz Fehler oder niedriger Hashrate seht:

Diagnose:

• Die aktuelle Frequenz ist an der Grenze der Stabilität der Spannung
• ihr benötigt mehr Spannung, um diese Frequenz stabil zu halten
• ihr benötigt eine bessere Kühlung

Maßnahme: Core Voltage erhöhen

1. Erhöhe die Core Voltage um +10mV (z.B. 1150 → 1160mV) für die instabilen Chips
2. Speichern & Neustart
3. Monitort erneut (mindestens 30 Minuten)
4. Sehr wichtig: Monitor die Temperatur intensiv!
   • Eine Spannungserhöhung erzeugt disproportional mehr Wärme
   • Beispiel: +10mV könnte +3–4°C an Temperatur hinzufügen

Szenario-Beispiel:

Versuch: 610MHz @ 1150mV
→ Nach 10min: 50 Invalid Shares, Hashrate sinkt

Lösung: 610MHz @ 1160mV (Spannung +10mv)
→ Nach 30min: 0 Fehler, aber Temp ist von 60°C auf 65°C gestiegen ✓
→ Akzeptabel! Speichern.

Nächster Versuch: 620MHz @ 1160mV
→ Nach 15min: Neue Fehler, 645 Invalid Shares
→ Wieder Spannung erhöhen? Vielleicht nicht. Temp ist bereits bei 65°C.
→ Lieber bei 610MHz @ 1160mV stoppen.

In meinem Falle ist aufgrund der besseren Kühlung das Gerät immer noch bei 60°, aber der Lüfter dreht schon deutlich schneller bei 54%

Schritt 6: Überhitzung erkannt? (Stop!)

Wenn während eines Versuches die Temperaturen in den gefährlichen Bereich schießen:

Sichere Schwellenwerte (harte Limiten):

• ASIC Core Temp > 70°C: Gefährliche Zone. Der Chip kann sich automatisch abschalten.
• VRM Temp > 85°C: Kritisch. Mehr Airflow ist notwendig

Wenn ihr dies seht: sofort stoppen!

Maßnahme: Rollback

1. Revertiert die letzte Frequenz- oder Spannungserhöhung, die diese Temperaturen ausgelöst hat
   • Wenn die Temp bei 620MHz zu hoch wurde, gehe zurück auf 610MHz
   • Oder wenn die Temp bei 1170mV stieg, geht zurück auf 1160mV
2. Speichert & Startet erneut, verifiziert, dass Temps zurück zu sicheren Werten gehen
3. Danach: Um weiter zu gehen, benötigt ihr Kühlungs-Upgrades:
   • Bessere/stärkere Ventilatoren
   • Niedrigere Umgebungstemperatur
   • Flüssigkeitskühlung (für extreme OC)
   • Bessere Airflow-Umgebung

Warnung: Das Ignorieren von Temperaturwarnungen ist der sicherste Weg zu permanenten Hardware-Schäden oder Bränden. Respektiert die Grenzen.

Schritt 7: Die OC-Grenze finden

Wiederholt diese Zyklen (Freq erhöhen → Monitoren → Falls instabil, Spannung erhöhen → Monitoren temps):

Ihr stoppt, wenn eine der folgenden Bedingungen erfüllt ist:

1. Ihr hast dein Ziel-Performance-Level erreicht
   • Z.B. wolltet ihr 20% mehr Hashrate, und ihr habt sie erreicht bei akzeptablen Temps & Spannungen ✓
2. Instabilität lässt sich nicht mit mehr Spannung beheben
   • Z.B. bei 700MHz @ 1200mV ist immer noch instabil bei 700MHz @ 1250mV
   • Das bedeutet: Die Hardware kann diese Frequenz physikalisch nicht stabil halten (selbst mit höherer Spannung)
   • Das ist die Hardware-Grenze
3. Thermische Grenzen erreicht
   • ASIC Temps sind konsistent > 70°C
   • VRM Temps nähern sich 85°C
   • Weitere Erhöhungen würden zu Shutdowns oder Schäden führen

Die "ideale" OC-Zone:

• Frequenz-Gewinn: +10–15% über Baseline (z.B. 550 → 610MHz) ist "konservativ"
• Spannungs-Erhöhung: +20–30mV über Baseline ist "moderat"
• Temperatur-Erhöhung: +15°C über Baseline wird noch akzeptiert
• Alles darüber: Aggressives OC mit hohem Risiko

Die perfekte OC-Einstellung finden: Ein vollständiges Beispiel

Angenommen, eure Baseline ist:

Frequency: 550MHz
Core Voltage: 1150mV
Temp: 60°C
Hashrate: 1070 GH/s (100%)
Power Draw: 18
Efficiency: 16.0 J/TH
Standard Kühlblock und Lüfter

OC-Versuch Gerät Nummer 1 mit Standard Kühler, schlechter ASIC Chip:

Fazit: Optimales OC-Fenster liegt bei 590 MHz @ 1160 mV

Warum Schritt 3 statt Schritt 5?

Während Schritt 5 (630 MHz @ 1170 mV) die höchste Hashrate von 1300 GH/s erreicht, ist dies nicht das beste Gesamtpaket:

• Stabilität: Schritt 3 ist vollständig stabil (0 Fehler), Schritt 5 ist nur Borderline
• Temperatur: 63°C vs. 68°C – noch im grünen Bereich
• Effizienz: 17.0 J/TH ist deutlich besser als 19.0 J/TH bei Schritt 5
• Hashrate-Gewinn: +6,4% gegenüber Schritt 1 (1100 → 1170 GH/s)
• Stromeffizienz: +2W mehr Verbrauch, aber stabiles System

Schritt 5 als risikobereite Alternative:

• +18,2% Hashrate (1300 GH/s)
• Aber: Borderline-Status, höhere Temps, schlechtere Effizienz
• Nur für aggressive Mining-Szenarien ohne Langzeitstabilität gefordert

OC Versuch Gerät Nummer 2 mit The Bitchin' Sink Kühler und dem Gelid Black Magic und zusätzlichen Effizienz Tuning

Fazit: OC-Versuch Gerät Nummer 2 – Optimales Fenster bei 640 MHz @ 1130 mV

Dieser Versuch zeigt deutlich bessere Ergebnisse als der erste. Mit dem The Bitcoins Sink Kühler und dem Gelid Black Magic Lüfter erreichen wir maximale Performance bei minimaler Spannung.

Optimaler Betriebspunkt: Schritt 8 / Schritt 10 (identisch)

• Hashrate: 1.31 TH/s (+22,4% vs. Baseline)
• Spannung: 1130 mV (deutlich niedriger als Schritt 6!)
• Temperatur: 60°C (sehr kühl)
• Stromverbrauch: 19.5W (sehr effizient)
• Effizienz: 18.5 J/TH
• Status: ✓ OK (vollständig stabil)

Warum besser als Schritt 6? Beide erreichen 1.31 TH/s, aber:

• Schritt 6: 1150mV, 23W, 20.0 J/TH
• Schritt 8/10: 1130mV, 19.5W, 18.5 J/TH

Mit 20mV weniger Spannung spart ihr 3.5W Stromverbrauch und verbessert die Effizienz um 7,5%. Das ist die perfekte Kurve für Langzeitbetrieb.

Grenzbereich erkannt: Schritt 9 (1120mV) zeigt Instabilität – 1130mV ist die sichere Untergrenze.

Fazit: Der bessere Kühler ermöglicht deutlich aggressiveres Tuning mit gleichzeitig besserer Effizienz. Das ist ein sehr sauberes Ergebnis.

Die Realität der OC-Risiken

1. Die Risiken sind real:
   • Potentielle Belohnung (höhere Hashrate) kommt mit erheblichen Risiken
   • Permanente Hardware-Schäden möglich
   • Brandgefahr durch Überhitzung
   • Herstellergarantie oft ungültig nach OC
2. Effizienz ist King:
   • Höhere Frequenz und Spannung erhöhen den Stromverbrauch drastisch
   • Berechnet: Kostet mich der Extra-Strom mehr als die Extra-Bitcoin-Hashrate wert ist?
   • Beispiel: +30% Strom für +10% Hashrate = schlechtes Geschäft
3. Stromqualität ist entscheidend:
   • In Regionen mit instabilen Stromnetzen (Brownouts, Spitzen, Solar/Wind-Fluktuationen) NICHT ÜBERTAKTEN
   • Instabile Stromversorgung während OC ist ein Sicherheitsrisiko
   • Investiere in hochwertige Stromversorgungen (Modularität, Überlastschutz, bessere Netzteile)
4. Umgebungsfaktoren:
   • In heißem Klima (>30°C Umgebungstemperatur): Sehr konservativ mit OC
   • In kaltem Klima (<15°C): Mehr Spielraum für OC
   • Raumluftqualität (Staub, Verschmutzung) wirkt sich auf Kühlung aus

Best Practices für sichere OC

✅ DO:

• Startet mit sehr kleinen Inkrementierungen (+5 MHz / +5mV wenn ihr sehr vorsichtig sein möchtet)
• Monitort obsessiv – mehrere Stunden lang, nicht nur 30 Minuten
• Setzt neue Einstellungen nicht über die Nacht, sondern eher am Tag wenn ihr das Gerät überwachen könnt
• Dokumentiert alles (Einstellungen, Temperatures, Fehlerate, Hashrate) für zukünftige Referenz
• Prioritäre Stabilität > Performance
• Haltet Backups eurer aktuellen stabilen Konfiguration

❌ DON'T:

• Vertraut nicht auf "Online-OC-Rechner" – das beste OC für euren Miner müsst ihr empirisch finden
• Erhöht nicht Freq UND Volt gleichzeitig – ihr wisst nicht, was was verursacht hat
• Ignoriert Temperaturwarnungen
• Verzweiflet nicht bei Fehlern – sie sind normal bei der OC-Grenze

Teil 2: Undervolting - Effizienz steigern und Lautstärke reduzieren

Was ist Undervolting

Während Overclocking die Hashrate maximiert, reduziert Undervolting die Spannung, um den Stromverbrauch zu senken. Das Beste: Undervolting ist sicher - es kann die Hardware nicht beschädigen. Treten Fehler auf oder sinkt die Hashrate zu stark, könnt ihr problemlos zur vorherigen Einstellung zurückkehren.

Warum Undervolting?

• Deutlich geringerer Stromverbrauch (10-20%)
• Niedrigere Temperaturen (5-15°C)
• Leiser Betrieb (niedrigere Lüftergeschwindigkeit)
• Längere Hardware-Lebensdauer als Bonus

Der Physik-Trick: Die Leistungsaufnahme steigt quadratisch mit der Spannung: P ≈ V² × f

• -10% Voltage = ca. -19% Stromverbrauch
• -15% Voltage = ca. -28% Stromverbrauch

Beispiel: BitAxe Undervolting

Ausgangssituation:

• Frequenz: 550 MHz
• Voltage: 1.15V (1150mV)
• Verbrauch: 18.7W
• Temperatur: 60°C
• Lüfter: 42%

Ziel:

• Verbrauch reduzieren
• Temperaturen senken
• Lüfter leiser bekommen

Der Undervolting-Prozess (Schritt für Schritt)

Schritt 1: Baseline dokumentieren

Notiert die aktuellen Werte:

• Voltage: 1150mV
• Frequency: 550 MHz
• Hashrate: z.B. 1070 GH/s (je nach Chip)
• Stromverbrauch: 18.7W
• Temperatur: 64-68°C
• Lüfter: 100%

Schritt 2: Erste Voltage-Reduktion

Konservativer Start: -25mV

• Neue Einstellung: 1100mV (1.10V)
• Frequenz bleibt bei 550 MHz
• Speichern und Neustart

Alternative - Aggressiver: -50 bis -75mV

• Bei BitAxe mit schlechter Kühlung oft möglich
• Neue Einstellung: 1100mV oder 1075mV

Schritt 3: Monitoring (30-60 Minuten)

Was prüfen:

• ✅ Läuft der Chip stabil? (keine Abstürze)
• ✅ Hashrate im erwarteten Bereich? (±2-3% ist okay)
• ✅ Temperatur gesunken? (sollte 3-8°C niedriger sein)
• ✅ Lüfter langsamer/leiser? (sollte automatisch runterregeln bei niedrigerer Temp)

Erfolgs-Indikatoren:

• Chip läuft ohne Fehler
• Hashrate nur minimal reduziert (0-5%)
• Temperatur deutlich niedriger (60°C oder weniger)
• Lüfter läuft bei 70-85% statt 100%
• Stromverbrauch: 14-16W statt 18W

Warnsignale:

• Häufige Hardware-Errors
• Hashrate bricht um >10% ein
• Chip wird instabil oder resettet

Schritt 4: Weiter optimieren (optional)

Wenn Schritt 2 erfolgreich war, könnt ihr weitermachen:

Nächster Schritt: weitere -10mv reduzieren

• Beispiel: Von 1100mV auf 1090mV
• Wieder 30Min testen

Typische BitAxe Sweet Spots:

• Konservativ: 1100mV (-50mV): ~16W, 62°C, Lüfter 85%
• Balanced: 1100-1050mV (-50 bis -100mV): ~14-15W, 58-60°C, Lüfter 70-80%
• Aggressiv: 1050-1030mV (-150 bis -170mV): ~12-13W, 55°C, Lüfter 60-70%
  • Achtung: Kann zu instabil sein, Hashrate-Verlust 5-10%

Schritt 5: Finales Testing

Nach 24 Stunden Laufzeit:

• Ist der Betrieb stabil geblieben?
• Keine ungewöhnlichen Fehler?
• Temperaturen konstant?

Falls instabil: Voltage um +10-20mV erhöhen

Die Bitaxe mit den neuen Settings:

Frequency + Voltage Co-Tuning

Für maximale Effizienz könnt ihr beides anpassen:

Beispiel:

• Voltage: 1025mV (-125mV)
• Frequency: 525 MHz (-25 MHz)

Ergebnis:

• Verbrauch: ~14W (-33%)
• Temperatur: ~52-55°C
• Lüfter: 30% (sehr leise!)
• Hashrate: ~1070 GH/s (-11%)

Wann sinnvoll:

• Lautstärke ist Hauptproblem
• Kühlung ist limitierend
• Hobby-Mining, Hashrate zweitrangig

Troubleshooting

Problem: Chip wird instabil → Voltage um +20mV erhöhen

Problem: Hashrate bricht stark ein (>10%) → Zu aggressives Undervolting, +10-20mV zurück

Problem: Temperatur sinkt kaum → Wärmeleitpaste prüfen, Kühler reinigen, mehr Voltage-Reduktion

Problem: Lüfter läuft weiter bei 100% → Lüfter-Steuerung prüfen

Wichtige Hinweise

✅ Sicher:

• Undervolting beschädigt Hardware nicht
• Jederzeit rückgängig machbar
• Keine langfristigen Risiken

✅ Vorteile:

• Deutlich leiser (Hauptziel bei BitAxe!)
• Weniger Stromkosten
• Kühlerer Betrieb
• Längere Lebensdauer

⚠️ Beachten:

• Jeder Chip ist anders (Silizium-Lotterie)
• Testet in kleinen Schritten
• 24h-Test für finale Settings
• Bei Instabilität einfach zurück zur vorherigen Einstellung

Teil 3: Beheben von niedriger Hashrate & Instabilität (Tuning Up)

Diagnose: Wo liegt das Problem

Wenn euer Miner Dashboard konsistent niedrige Hash-Submissions ("Invalid Shares", "Summit-Fehler") von spezifischen Chips oder dem gesamten Gerät zeigt, oder die Hashrate deutlich unter den Spezifikationen liegt:

Mögliche Ursachen:

1. Unzureichende Spannung für die aktuelle Frequenz (häufigste Ursache)
2. Schlechte thermische Anbindung (Chip überhitzt lokal)
3. Fehlerhafte Chip/Hashboard
4. Instabile Stromversorgung
5. Firmware-Bug oder falsche Pool-Konfiguration

Ziel dieses Teils

Finde die minimale stabile Spannung, die alle Fehler eliminiert und die erwartete Hashrate bei der aktuellen Frequenz wiederherstellt. Dies optimiert die Energieeffizienz (J/TH) und redzuiert die Fehlerrate.

Der sichere Tuning-Prozess

Schritt 1: Diagnose & Identifikation

Nutzt eurer Miner-Management-Interface (AxeOS, Braiins OS+, StockOS, etc.) um zu überprüfen:

• Expected Hashrate: Stimmt die Tatsächliche Hashrate mit der Exptected Hashrate überein?
• Submission Rate: Wie viele gültige Shares sendet jeder Chip?

Schritt 2: Baseline dokumentieren

Notiert die aktuellen Einstellungen für alle Chips oder Problem-Chips:

• Core Voltage: z.B. 1150mV
• Frequency: z.B. 550MHz
• Aktuelle Hashrate: Notiere die beobachtete Rate
• Fehler-Rate: z.B. 10% Invalid Shares
• Niedrigere Hashrate als die Exptected Hashrate

Schritt 3: Kleine Spannungserhöhung

Erhöht die Core Voltage für die problematischen Chips um +5mV (z.B. von 1150mV auf 1155mV).

Schritt 4: Speichern & Neustart

• Speichert die neuen Einstellungen im Miner-OS
• Führt einen vollständigen Neustart durch
  • Dies stellt sicher, dass alle Komponenten mit den neuen Parametern initialisiert werden
  • Verhindert Fehler durch Cache oder teilweise geladene Konfigurationen

Schritt 5: Intensives Monitoring (15-30+ Minuten)

Beobachtet folgende Metriken sehr genau:

5a) Submission Rate & Hashrate

• Haben die Fehlerquoten ("Invalid Shares", "HW Errors") abgenommen?
• Ist die beobachtete Hashrate jetzt näher an der erwarteten Hashrate für diese Frequenz?
• Beispiel: Bei 625MHz solltet ihr die gleiche Hashrate sehen wie zuvor, nur ohne Fehler

5b) Temperatur

• Sind die ASIC-Core-Temperaturen angestiegen? (Ja, aber wie viel?)
• Erwartungswert: +1–3°C pro +10mV Spannungserhöhung ist typisch
• Überwachung kritischer Schwellenwerte:
  • ASIC Temp nicht über 70
  • VRMs (Voltage Regulators) < 95°C

5c) Hardware Errors

• Erscheinen neue oder verschiedene Fehlertexte im Log?
• nonce_range_err: Könnte auf Stromprobleme hindeuten

Wo man nach Logs sucht:

• AxeOS: Web-Interface > Logs > Download Full Log oder im Dashboard
• NerdQ OS: Miner > Log Viewer im Web-Interface

Schritt 6: Iterieren (falls nötig)

Wenn die Fehlerquoten nach 30 Minuten Monitoring immer noch hoch sind:

1. Wiederhole Schritt 3: Erhöhe die Spannung um weitere +10mV (z.B. 1160 → 1170mV)
2. Führe Schritte 4 & 5 erneut durch
3. Wichtig: Gehe schrittweise vor! Nicht in 50mV-Sprüngen erhöhen.

Typische Progression bei Problemen:

1150mV → 50% Fehler → 1160mV → 20% Fehler → 1170mV → 5% Fehler → 1180mV → 0% Fehler ✓

Schritt 7: Diagnose eines Defekts

Wenn ihr nach mehreren Inkrementierungen (z.B. bis 1200–1200mV) immer noch keine Verbesserung siehst, liegt das Problem wahrscheinlich nicht an der Spannung oder der Chip ist wirklich kein Silikon Lottery Win:

Mögliche Probleme:

1. Defekter Chip/Board: Das Hashboard könnte physikalisch beschädigt sein
2. Schlechte Wärmeableitung: Wärmepaste ist trocken oder wurde falsch aufgetragen
3. Schlechte Stromversorgung zu diesem Board: Beschädigtes Stromleitungskabel oder Stecker
4. Firmware-Bug: Seltener, aber möglich
5. ASIC Binning: sehr schlechte ASIC Qualität

Diagnose-Schritte:

• Extrahiert die vollständigen Logs und teilt sie mit der Community
• Wenn thermisch: Überprüft die Wärmepaste-Konsistenz und Aufpressdruck
• Im Extremfall: Wechsel das Board oder den Chip aus, oder sendet das Gerät zurück wo ihr es gekauft habt

Fazit

Nutzt dieses Wissen weise. Beginnt klein, überwacht obsessiv, priorisiert Stabilität und Kühlung, und respektiert immer die Grenzen der Hardware. Glücklich (und sicheres) Mining! ⛏️

Bei der praktischen Umsetzung zeigt sich häufig: Ein OC lässt sich in den meisten Fällen rückgängig machen und die Hardware wird wieder normal, solange keine Überhitzung stattgefunden hat. Wenn die Hardware nicht physikalisch beschädigt wurde, könnt ihr zu den Werkseinstellungen zurückkehren – allerdings sind thermische oder elektrische Schäden oft permanent.

Ein wichtiger Punkt: Unterschiedliche Chip-Generationen (BM1368, BM1370, etc.) sollten praktisch nicht mit denselben Einstellungen getuned werden. Während es theoretisch möglich ist, haben unterschiedliche Generationen unterschiedliche Optimalpunkte. Nutzt separate Einstellungen pro Generation, wenn möglich.

Im Shop verkaufen wir Geräte, welche in der PowerSave Edition auf maximale Effizienz, und in der Special beziehungsweise Black Edition auf Leistungsfähigkeit bei angepasster Chipspannung und Chipfrequenz optimiert worden sind, ohne dass ihr die Garantie verliert. Schaut mal vorbei!

The post Tuning & Overclocking Guide für Bitaxe und NerdQ Miner appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Solomining ist die reinste Form des Minings, bei der ihr direkt mit eurem eigenen Equipment arbeitet, und euch mit der Theorie und Praxis auseinander setzt. Ihr habt die volle Kontrolle über euren Betrieb, die Belohnungen und auch die Herausforderungen. Beim Prozess des Minings könnt ihr solides Verständnis zentraler Konzepte wie Hashrate, Block Templates, Difficulty und der Technik, die hinter der Blockchain steckt erlernen.

Diese Bibel richtet sich an Anfänger, die bisher keinen Plan haben, wie sie starten sollen, aber die Motivation mitbringen, tiefer in die Materie einzutauchen. Schritt für Schritt erkläre ich euch wichtige Begriffe, Technologien und Prozesse, damit ihr euch sicher in dieser faszinierenden Welt bewegen könnt.

Auf geht's – schnappt euch eure Mining-Hardware und lasst uns gemeinsam in die Grundlagen eintauchen! 😊

Die Mining Bibel wurde mit mondayshot geschrieben. Sehr vieles, vor allem die Pool Informationen, Difficulty Berechnungen und der Mining Ablauf stammen von Ihm. Ein Link zur Spende findet ihr unten.

Was ist Solo-Mining

Solo Mining (Lottery Mining) bedeutet, dass ihr alleine versucht, einen Bitcoin-Block zu finden und die volle Belohnung (3.125 BTC + Transaktionsgebühren) zu erhalten. Dabei könnt ihr entweder eure eigenen Node betreiben mit einem eigenen Solo-Pool wie zum Beispiel Public-Pool von Benjamin Wilson oder über einen Solo Mining Pool eines bestimmten Anbieters arbeiten, der die Infrastruktur bereitstellt.

Warum macht man Solo Mining

• Volle Belohnung: Ihr erhaltet 100 % der Blockbelohnung, ohne sie mit anderen Minern zu teilen.
• Unabhängigkeit: Ihr seid nicht auf klassische Pools angewiesen und könnt eure eigene Mining-Strategie verfolgen.
• Lotterie-Charakter: Jeder Hash ist wie ein Lottoschein, und es geht um den großen Gewinn – wenn ihr erfolgreich seid.

Solo Mining ist ideal für risikofreudige Miner, die auf einen großen Gewinn hoffen, und weniger für konstante Einnahmen gedacht. Es erfordert Geduld und eine grosse Portion Glück um einen Block zu finden, aber es macht Spass, und man lernt viel Theorie und auch Praxis zum Handwerk des Bitcoin Minings.

Wie läuft das Mining genau ab

Der Prozess vom Generieren eines Hashes bis zur Veröffentlichung eines gültigen Blocks sieht grob gesagt so aus:

Block Template

1. Der Pool verteilt mit "mining.notify" ein neues Block Template, entweder weil die Transaktionen aktualisiert wurden oder weil das Netzwerk einen neuen Block gefunden hat.

Bei der Übermittlung eines Block Template werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
jobId, prevHash, coinbase part1, coinbase part2, merkle_branch, version, bits, timestamp, clear jobs

Generieren des Hashes

2. Der Miner ergänzt diese Daten um:
   👾 extraNonce2 (selbst generiert)
   👾 nonce (startet bei 0)
3. Aus diesen Daten wird der Block-Header zusammengestellt.
4. Der Block-Header wird zweimal durch die SHA256-Funktion gehasht.

Variieren der Nonce

5. Wenn der generierte Hash nicht unter dem Work-Difficulty Target liegt, erhöht der Miner die Nonce um 1 und wiederholt den Hashing-Prozess.
6. Dieser Vorgang wird Milliarden Mal pro Sekunde wiederholt.
7. Wenn alle möglichen nonce-Werte (2^32) erschöpft sind, ändert der Miner:
   👾 extraNonce2 oder
   👾 timestamp (innerhalb erlaubter Grenzen)
   und beginnt wieder bei 0 mit dem Hochzählen von den möglichen nonce-Werte (2^32 = 4'294'967'296)

Übermittlung an den Pool

8. Wenn ein Hash gefunden wird, der unter der vom Pool vorgegebenen Work-Difficulty liegt, wird der Share mit "mining.submit" an den Pool übermittelt.

Bei der Übermittlung eines Shares werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
id, userId, jobId, extraNonce2, ntime, nonce, versionMask

9. Der Pool überprüft den Share.

Veröffentlichung eines gültigen Blocks

10. Wenn der gefundene Hash auch unter dem Netzwerk-Difficulty Target liegt, erkennt der Pool einen gültigen Block.
11. Der Pool stellt den vollständigen Block zusammen:
    👾 Block-Header mit den vom Miner gefundenen Werten
    👾 Coinbase-Transaktion mit Belohnung für den Miner
    👾 Transaktionen
12. Der Pool broadcastet den Block sofort an verbundene Bitcoin-Nodes.
13. Die Nodes validieren den Block und leiten ihn weiter.
14. Andere Miner beginnen, auf dem neuen Block aufzubauen.
15. Der Pool sendet einen neuen Mining-Job mit einem neuen Block Template an alle verbundenen Miner.

Was ist die "Nonce"

Eine Nonce (Number Only Used Once) ist ein 32-Bit-Wert im Blockheader, den Miner während des Mining-Prozesses kontinuierlich ändern. Sie wird verwendet, um neue Hashes zu generieren.

Funktion der Nonce

• Miner ändern die Nonce bei jedem Versuch, einen gültigen Hash zu finden, der die Difficulty-Vorgaben erfüllt.
• Jede Änderung der Nonce führt zu einem komplett neuen Hash, dank der zufälligen Natur der Hash-Funktion.

Wenn die Nonce alle möglichen Werte durchlaufen hat, ändert der Miner andere Felder im Blockheader (z. B. den Timestamp oder die Coinbase-Transaktion), um weiterhin neue Hashes zu erzeugen.

Größe der Nonce

• Die Nonce ist ein 32-Bit-Wert (4 Bytes), was bedeutet, dass es insgesamt: 2^32=4.294.967.296 mögliche Werte gibt.

Die Nonce ist somit ein zentraler Bestandteil des Proof-of-Work-Prozesses.

Was ist die Coinbase Transaktion

Die Coinbase-Transaktion ist eine spezielle Transaktion, die im Mining-Prozess erstellt wird und die Block-Belohnung (Block Reward) an den Miner auszahlt, der den Block erfolgreich gefunden hat. Sie ist immer die erste Transaktion in einem Block und hat einige besondere Eigenschaften.

Eigenschaften der Coinbase-Transaktion

1. Erzeugung der Block-Belohnung:
   • Die Coinbase-Transaktion generiert die neue Bitcoin-Belohnung, die aktuell (Stand 2024) 3.125 BTC + Transaktionsgebühren beträgt.
   • Diese Belohnung wird direkt an die Wallet-Adresse des Miners oder des Mining-Pools ausgezahlt.
2. Keine Eingänge (Inputs):
   • Im Gegensatz zu normalen Bitcoin-Transaktionen hat die Coinbase-Transaktion keine Inputs, weil die Belohnung neu generiert wird.
   • Sie enthält jedoch eine spezielle Nonce oder zusätzliche Daten im Input-Feld, die Miner ändern können, um neue Hashes zu erzeugen.
3. Speicherort für ExtraNonce:
   • Miner nutzen die Coinbase-Transaktion, um eine ExtraNonce einzufügen, wenn die reguläre Nonce im Blockheader erschöpft ist. Änderungen an der ExtraNonce führen zu einer Änderung der Merkle Root, wodurch neue Hashes erzeugt werden können.
4. Transaktionsgebühren:
   • Neben der Block-Belohnung enthält die Coinbase-Transaktion auch die Summe aller Transaktionsgebühren, die von den im Block enthaltenen Transaktionen gezahlt werden.

Wie sieht eine Coinbase-Transaktion aus

• Input:
  • Kein normaler Input. Stattdessen ein spezielles Feld, das oft vom Miner genutzt wird, um zusätzliche Daten oder eine Botschaft einzufügen.
• Output:
  • Die Auszahlung geht an die Wallet-Adresse des Miners oder des Pools.

Beispiel einer Coinbase-Transaktion

In einem Block kann die Coinbase-Transaktion so aussehen:

• Input: Spezieller Wert (z. B. Nonce, Nachrichten).
• Output: Auszahlung an die Adresse des Miners.

Die Coinbase-Transaktion ist also die erste Transaktion in jedem Block und dient dazu, die Mining-Belohnung und Transaktionsgebühren an den Miner auszuzahlen. Sie hat keine Eingänge, sondern generiert neue Bitcoins, und kann von Minern angepasst werden, um den Hashing-Prozess zu unterstützen.

Die Coinbase unter Stratum V2

Wer die Coinbase-Transaktion zusammenstellt, hängt davon ab, wer das Block-Template baut. Bei Stratum V1 (und auch bei SV2 ohne JDP) baut der Pool die Coinbase – beim Solo-Mining auf einem Public-Pool steht darin bereits eure eigene BTC-Adresse als Output, sodass die Belohnung direkt an euch geht. Mit dem Job Declaration Protocol (JDP) baut hingegen ihr selbst das Template gegen euren eigenen Node – und damit auch die Coinbase. Beim gepoolten SV2 gilt dann die einfache Regel: Der Pool erzwingt nur, dass sein eigener Auszahlungs-Output (für die Reward-Verteilung) enthalten ist; über den gesamten Rest des Blocks bestimmt ihr. Mehr dazu im Abschnitt „Stratum V2 – das modulare Mining-Protokoll".

Was sind Shares

Shares sind keine Teillösungen eines gültigen Blocks, sondern vielmehr Nachweise für die Arbeitsleistung eines Miners. Beim Mining versucht ein Miner, einen gültigen Block zu finden, der die von der Blockchain vorgegebene globale Schwierigkeit (Network Difficulty) erfüllt. Da diese Schwelle sehr hoch ist, wird innerhalb eines Mining-Pools mit einer niedrigeren Schwierigkeit gearbeitet – der sogenannten Share Difficulty.

Wie funktionieren Shares

Man kann sich das so vorstellen, als würde der Miner regelmäßig Blöcke generieren, die die Share Difficulty erfüllen, aber die Network Difficulty nicht erreichen. Diese Blöcke sind technisch gesehen ungültig für die Blockchain, da sie nicht genug Nullen im Hash aufweisen, werden aber dennoch vom Pool akzeptiert, um die Arbeitsleistung des Miners zu messen. Jeder solche "kleine Block" wird als Share gezählt.

Warum sind Shares wichtig

Shares dienen dem Mining-Pool dazu, die Beiträge der einzelnen Miner fair zu bewerten. Sobald einer der Miner zufällig einen Hash findet, der die Network Difficulty erfüllt (also einen gültigen Block), wird dieser Block an die Blockchain übermittelt. Die Belohnung, die der Pool dafür erhält, wird dann unter den beteiligten Minern aufgeteilt – basierend auf der Anzahl ihrer Shares.

Accepted Shares

Shares die vom Miner erfolgreich an den Pool übermittelt und akzeptiert wurden.

Rejected Shares

Shares die vom Miner zwar an den Pool übermittelt, jedoch nicht akzeptiert wurden, weil zB
▪ euer Share eine zu geringe Difficulty aufweist (das Thema bei NerdMiner und Diff < 1)
▪ euer Share wegen hoher Latenzen zu spät eingereicht wurde und bereits ein neues Block Template verteilt wurde
▪ euer Share veraltet ist, dass heisst das zwischenzeitlich ein neuer Block gefunden wurde und dein Share somit auf einem veralteten Block Template erstellt wurde
▪ euer Share doppelt eingereicht wurde
▪ euer Share gegen Pool-Richtlinien verstösst (zB. blockt kano.is IP-Adressen von CPU-Miner)

Der Prozess besteht im Wesentlichen darin, dass Miner kontinuierlich Hashes berechnen und dabei Shares generieren. Irgendwann trifft ein Miner zufällig auf einen Hash, der genügend Nullen hat, um einen gültigen Block zu erstellen. Dieser Block wird an die Blockchain angehangen, und alle Miner, die Shares beigesteuert haben, werden entsprechend entlohnt – abhängig vom Vergütungsmodell des Pools.

Shares und Channels unter Stratum V2

Bei Stratum V1 läuft die gesamte Kommunikation über eine einzige, textbasierte Verbindung, auf der die oben beschriebene Worker-Difficulty (vardiff) dynamisch angepasst wird. Stratum V2 strukturiert dieselbe Verbindung stattdessen in typisierte Channels, was die Share-Übermittlung effizienter und flexibler macht. Drei Channel-Typen sind dabei relevant:

• Standard Channel – für einzelne ASIC-Geräte wie eine Bitaxe. Er deckt bis zu rund 280 TH/s pro nTime-Wert ab und ist der Normalfall für Heim-Solo-Miner.
• Extended Channel – für Proxies und grössere Setups. Er erlaubt eigenes Extranonce-Rolling, sodass der Miner mehr Nonce-Raum selbst durchläuft und seltener mit dem Pool sprechen muss.
• Group Channel – bündelt mehrere Standard Channels hinter einem einzelnen Proxy, praktisch für Farmen mit vielen Geräten.

In der Praxis unterstützen die Firmwares bislang unterschiedliche Channel-Typen: BraiinsOS setzt aktuell ausschliesslich auf Standard Channels. Bei der quelloffenen Hardware sind wir sogar einen Schritt weiter – die Firmware beider Geräte stammt von uns (yourdevice): Für die Bitaxe haben wir sowohl Standard- als auch Extended-Channel-Unterstützung umgesetzt, die NerdQaxe spricht Extended Channels.

Zusammen mit dem binären Nachrichtenformat und der deutlich geringeren Latenz (Block-Wechsel statt in Hunderten Millisekunden im Bereich weniger Millisekunden) sorgt diese Struktur dafür, dass eure Shares schneller und mit weniger Overhead beim Pool ankommen als unter V1.

Difficulty

Network Difficulty (Netzwerk-Schwierigkeit)

Die Network Difficulty ist eine globale Metrik, die von der Bitcoin-Blockchain selbst festgelegt wird und den Schwierigkeitsgrad beschreibt, einen gültigen Block zu finden. Sie wird etwa alle 2016 Blöcke (etwa alle zwei Wochen) dynamisch angepasst, damit das Netzwerk im Durchschnitt alle 10 Minuten einen neuen Block generiert.

Eigenschaften der Network Difficulty:

1. Global und für alle Miner gleich:
   • Jeder Miner im Netzwerk muss sich an die aktuelle Network Difficulty halten, um einen gültigen Block zu finden.
2. Berechnung:
   • Die Difficulty ist proportional zur Zeit, die das Netzwerk benötigt hat, um die letzten 2016 Blöcke zu minen.
   • Formel:
     Neue Schwierigkeit = Alte Schwierigkeit × (Zielzeit für 2016 Blöcke / Tatsächliche Zeit für 2016 Blöcke)
3. Beeinflusst den Mining-Prozess:
   • Eine höhere Network Difficulty bedeutet, dass Miner mehr Rechenleistung benötigen, um einen Block zu finden.
   • Ziel: Die Blockzeit von 10 Minuten im Durchschnitt konstant halten, unabhängig von der Gesamt-Hashrate im Netzwerk.
4. Ausdruck in Zahlen:
   • Network Difficulty wird als eine große Zahl dargestellt, die das Verhältnis zwischen einem Ziel-Hash und dem maximal möglichen Hash beschreibt.

Worker Difficulty (Arbeiter-Schwierigkeit)

Die Worker Difficulty ist eine lokal festgelegte Schwierigkeit, die in Mining-Pools oder Solomining-Systemen verwendet wird, um zu bestimmen, wie schwer es für einen einzelnen Worker (einen Mining-Prozess oder -Gerät) ist, einen Share (einen Teilerfolg) zu finden.

Eigenschaften der Worker Difficulty

1. Individuell anpassbar:
   • Die Worker Difficulty wird von einem Mining-Pool oder der Mining-Software festgelegt, um die Leistung einzelner Mining-Geräte zu berücksichtigen.
   • Ziel: Ein gleichmäßiger Strom an Shares, unabhängig von der Rechenleistung des Miners.
2. Shares anstatt Blöcke:
   • Miner arbeiten mit einer lokal niedrigeren Schwierigkeit und reichen ihre gefundenen Shares an den Pool weiter. Der Pool aggregiert die Shares und arbeitet auf der Network Difficulty, um einen gültigen Block zu finden.
3. Warum gibt es Worker Difficulty?
   • Unterschiedliche Miner haben unterschiedliche Hashraten. Ein Gerät mit geringer Leistung würde kaum Shares generieren, wenn es direkt mit der Network Difficulty arbeiten müsste. Daher wird die Worker Difficulty so angepasst, dass jedes Gerät regelmäßig Shares liefern kann.
4. Automatische Anpassung (Stratum-Protokoll):
   • Mining-Pools passen die Worker Difficulty dynamisch an (z. B. mit „vardiff“, variable difficulty), um sicherzustellen, dass Miner ungefähr einen Share alle 5–10 Sekunden liefern.
5. Wert:
   • Worker Difficulty ist immer niedriger als die Network Difficulty, da sie für die lokale Rechenleistung optimiert ist.

Unterschiede zwischen Network und Worker Difficulty

Defintion und Festlegung der Difficulty oder Netzwerk-Schwierigkeit

Difficulty = Hash(max_target) ÷ Hash(current_target)

Mit Hash(max_target) ist die Difficulty = 1 gemeint und sie repräsentiert die grösstmögliche Zahl bzw. die geringstmögliche Schwierigkeit.
Hash(current_target) repräsentiert die notwendige Schwierigkeit eines Hashes, bedeutet je kleiner diese Zahl, desto schwieriger.
Die Difficulty oder Netzwerk-Schwierigkeit ist das Ergebnis aus der Division der beiden Werte Hash(max_target) und Hash(current_target).

Hier die Berechnung am Beispiel des Block_752868 und der damaligen Difficulty = 30.98T = 30'977'051'760'460

Hash(max_target) bzw. Difficulty = 1 ist bei Bitcoin als 0x1d00ffff definiert, als Hexadezimalwert ist das ein Hash mit 8 führenden Nullen:
= 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Da bei Bitcoin der Hash(max_target) als Gleitkommazahl gespeichert wird, wird dieser abgeschnitten:
= 00000000ffff0000000000000000000000000000000000000000000000000000

Dieser Hexadezimalwert wird in ein Dezimalwert konvertiert:
= 26959535291011309493156476344723991336010898738574164086137773096960
= 2.696E+67 = Hash(max_target)

Da wir nun Hash(max_target) = 2.696E+67 und die Difficulty 30'977'051'760'460 kennen, können wir die notwendige Schwierigkeit eines Hashes, also Hash(current_target), bestimmen:

Hash(max_target) ÷ Difficulty = Hash(current_target)
= 2.696E+67 ÷ 30'977'051'760'460 = 8.703E+53 = Hash(current_target)

Für einen gültigen Block muss der Hash des Blocks_752868 kleiner und damit schwieriger sein, als die notwendige Schwierigkeit:
Hash(block_752868) < Hash(current_target) = valid Block

Hash(block_752868)
= 000000000000000000023331c3817233e49bb141216fea1a75a3643a04410bde

Dieser Hexadezimalwert wird in ein Dezimalwert konvertiert:
= 210716037705402490166328113539479810618942705228647390
= 2.107E+53 = Hash(current_target)

2.107E+53 < 8.703E+53 = valid Block ☑️

Der Hash vom Block ist tatsächlich sehr klein und hat damit eine sehr hohe Schwierigkeit:

Hash(max_target) ÷ Hash(block_752868) = Diff(block_752'868)
2.696E+67 ÷ 2.107E+53 = 127'942'493'531'047

Diff(block_752868) = 127'942'493'531'047 = 127.94T

Warum Network und Worker Difficulty wichtig sind

• Network Difficulty:
  • Regelt das Gesamtgleichgewicht der Bitcoin-Blockchain und sorgt für Stabilität dass alle 10 Minuten ein Block gefunden wird.
• Worker Difficulty:
  • Optimiert den Mining-Prozess auf individueller Ebene, insbesondere bei Pools, um sicherzustellen, dass jeder Miner sinnvoll zur Blockfindung beiträgt.

Das Diagramm zeigt den Unterschied zwischen der Network Difficulty (global und konstant über 2016 Blöcke und wird dann angepasst) und der Worker Difficulty, die sich je nach Hashrate des Miners unterscheidet:

• Network Difficulty (gestrichelte Linie): Bleibt auf globaler Ebene konstant während 2016 Blöcke und wird nur dann angepasst, um die Blockzeit stabil zu halten.
• Worker Difficulty (High Hashrate) (durchgezogene Linie): Erhöht durch schneller für Miner mit höherer Rechenleistung.
• Worker Difficulty (Low Hashrate) (gepunktete Linie): ist geringer, da die Hashrate niedriger ist und eine kleinere Schwierigkeit besser geeignet ist. Je nachdem wieviel Hashleistung das Gerät liefert, wird aber auch hier die Worker Difficulty angepasst.

Was sind Block Templates

Ein Block Template ist eine Vorlage für einen neuen Block in der Blockchain. Es enthält alle notwendigen Daten, die ein Miner benötigt, um einen gültigen Block zu erstellen und an das Netzwerk zu senden. Block Templates werden in der Regel von einer Bitcoin-Node generiert und sind ein zentraler Bestandteil des Mining-Prozesses.

Bestandteile eines Block Templates

1. Header-Daten:
   • Version: Gibt die Softwareversion des Bitcoin-Protokolls an.
   • Previous Block Hash: Verweis auf den Hash des vorherigen Blocks in der Blockchain.
   • Merkle Root: Der Wurzelhash des Merkle-Baums, der alle Transaktionen im Block repräsentiert.
   • Timestamp: Aktuelle Zeit des Nodes.
   • Difficulty Target: Die Schwierigkeitsgrenze, die der Block erfüllen muss.
   • Nonce: Ein Wert, der während des Minings variiert, um einen gültigen Blockhash zu finden.
2. Liste von Transaktionen:
   • Enthält alle Transaktionen, die in den neuen Block aufgenommen werden sollen. Diese Transaktionen stammen aus dem Mempool (Memory Pool), in dem alle unbestätigten Transaktionen gespeichert werden.
3. Coinbase-Transaktion:
   • Die erste Transaktion im Block, die die Mining-Belohnung an die Adresse des Miners auszahlt. Dies ist der einzige Weg, neue Coins in Umlauf zu bringen.
4. Zusätzliche Felder:
   • Informationen über Gebühren, Höhe des Blocks, und manchmal sogar zusätzliche Metadaten.

Wie werden Block Templates generiert

Block Templates werden normalerweise von einem Bitcoin-Node mit Hilfe der JSON-RPC-Schnittstelle bereitgestellt. Ein Miner bzw. der Stratum Server kann die Methode getblocktemplate verwenden, um eine aktuelle Vorlage zu erhalten.

Beispiel für einen RPC-Aufruf:

bitcoin-cli getblocktemplate '{"capabilities":["coinbasetxn", "workid"]}'

Die Node gibt daraufhin ein JSON-Objekt zurück, das alle oben genannten Daten enthält.

Eine Antwort könnte in etwas so aussehen:

{
  "version": 536870912,
  "previousblockhash": "0000000000000000000bae6ebf7a123456789abcdef0000000000000abcde123",
  "transactions": [
    {
      "data": "0100000001abcdef...", 
      "txid": "123456789abcdefabcdef123456789abcdef123456789abcdef123456789abcde",
      "hash": "abcdefabcdef123456789abcdefabcdef123456789abcdefabcdef123456789abc",
      "depends": [],
      "fee": 50000,
      "sigops": 2
    }
  ],
  "coinbaseaux": {
    "flags": "062f503253482f"
  },
  "coinbasevalue": 312500000, 
  "target": "0000000000000000000f00000000000000000000000000000000000000000000",
  "mintime": 1697097600,
  "mutable": ["time", "transactions", "prevblock"],
  "noncerange": "00000000ffffffff",
  "sigoplimit": 80000,
  "sizelimit": 4000000,
  "curtime": 1697098502,
  "bits": "170c47d7",
  "height": 809349
}

In diesem Beispiel ist nur eine einzige Transaktion enthalten. Ein Template wäre natürlich viel viel grösser.

Erklärung der Felder

1. version:
   • Gibt die Blockversion an, die verwendet wird. Die Miner müssen diese in den Blockheader einfügen.
2. previousblockhash:
   • Der Hash des vorherigen Blocks, der in den neuen Block referenziert wird, um die Blockchain zu verketteten.
3. transactions:
   • Eine Liste der Transaktionen, die im Block enthalten sein sollen.
   • data: Die vollständige, serialisierte Transaktion.
   • txid: Die ID der Transaktion.
   • hash: Hash der Transaktion.
   • fee: Die Transaktionsgebühr (in Satoshis).
   • sigops: Anzahl der Signaturoperationen der Transaktion.
4. coinbaseaux:
   • Zusätzliche Daten, die in der Coinbase-Transaktion enthalten sein sollen, wie Mining-Pool-Flags.
5. coinbasevalue:
   • Die Gesamtbelohnung (Blockreward + Transaktionsgebühren), die an den Miner ausgezahlt wird (in Satoshis).
6. target:
   • Der Zielwert, unter den der Hash fallen muss, damit der Block gültig ist (abhängig von der Difficulty).
7. mintime:
   • Die frühestmögliche Zeit (UNIX-Timestamp), zu der der Block erstellt werden kann.
8. mutable:
   • Eine Liste von Feldern, die der Miner anpassen darf, z. B. time, transactions oder prevblock.
9. noncerange:
   • Der Wertebereich der Nonce, die der Miner verändern darf, um neue Hashes zu erzeugen.
10. sigoplimit:
    • Die maximale Anzahl an Signaturoperationen, die im Block erlaubt sind.
11. sizelimit:
    • Die maximale Blockgröße in Bytes (bei Bitcoin 4 MB, einschließlich SegWit-Daten).
12. curtime:
    • Die aktuelle Zeit, zu der der Blocktemplate erstellt wurde (UNIX-Timestamp).
13. bits:
    • Der kompakte Zielwert (Difficulty) für den Block in komprimierter Form.
14. height:
    • Die Höhe des Blocks in der Blockchain (1-basierte Nummerierung).

Block Templates also sind ein zentraler Bestandteil des Mining-Prozesses. Sie enthalten die Daten, die ein Miner benötigt, um einen Block zu erstellen und zu validieren. Für Solominer die ihren eigenen Mining Pool beitreiben, bieten sie maximale Kontrolle über den Inhalt des Blocks und die Auszahlung der Belohnung. Ein Blocktemplate, der eure BTC-Adresse enthält, kann nicht mehr nachträglich von Bitcoincore verändert werden, ansonsten würde der Hash des Blocks nicht mehr stimmen.

Block Template Hash Simulator

Ändert bestimmte Felder im Template ab, und schaut, wie sich der Hash verändert. Ihr könnt so lange ändern wie ihr wollt, und auch den ganzen Tag auf der Tastatur herumdrücken, und ihr werdet verstehen, wie schwierig es ist, einen Hash zu generieren, der eine bestimmte Anzahl an Nullen enthält.

Block Template Updates ckpool vs public pool

Häufig stellt sich die Frage, ob ckpool besser fürs Mining geeignet ist, weil sie alle 30 Sekunden ein neues Blocktemplate schicken, anstatt alle 60 Sekunden wie zum Beispiel Public Pool. Wenn euer Template seltener geupdated wird, könnte eine Transaktion mit viel Gebühr bereits in aktuelleren Templates sein, aber noch nicht in eurem. Extrembeispiel: Die fehlerhafte Paypal-Konsolidierung 2023 ist nicht in eurem Template, wenn eure Bitaxe kein „aktuelles“ Template hat. Damit entgehen euch in diesem Fall die zusätzlichen 19BTC an Fees.

Block Templates unter Stratum V2

Alles in diesem Abschnitt – der Pool schickt euch alle 30 bzw. 60 Sekunden ein frisches Template, und je aktueller, desto besser – beschreibt das Stratum-V1-Modell, bei dem der Pool das Block-Template baut und an euch verteilt. Mit dem Job Declaration Protocol (JDP) von Stratum V2 dreht sich genau das um: Ihr baut das Template selbst, lokal gegen euren eigenen Bitcoin-Node. Damit ist die Frage „wie oft schickt mir der Pool ein aktuelles Template?" hinfällig – ihr zieht die Transaktionen in Echtzeit direkt aus eurem eigenen Mempool und entscheidet selbst, was in den Block kommt. Der Pool prüft dann nur noch, dass sein Auszahlungs-Output enthalten ist, und übernimmt das Share-Accounting. Voraussetzung ist wie erwähnt ein Pool mit JDS-Unterstützung und ein eigener Node – die Details dazu findet ihr im Abschnitt „Stratum V2 – das modulare Mining-Protokoll" weiter unten.

Was ist, wenn ich mehrere Miner habe, arbeiten die dann alle am selben Template?

Nein, dafür gibt es eben zum Beispiel die ExtraNonce. Die ExtraNonce ist Teil des Stratum mining protocol und befindet sich im Header der Coinbase Transaktion. Die ExtraNonce besteht aus 2 Teilen:
ExtraNonce1 und ExtraNonce2:

👉 Die ExtraNonce1 wird dem Miner vom Pool zur Verfügung gestellt und dient als Identifikator
mining.subscribe("user agent/version", "extranonce1")

👉 Die ExtraNonce2 wird vom Miner während seiner Arbeit ständig geändert und mit jedem Share an den Pool übermittelt
mining.submit("username", "job id", "ExtraNonce2", "nTime", "nOnce")

Mit diesem 'unique string' oder 'Identifikator' ist sichergestellt, dass 2 Worker selbst bei identischem Block Template / Nonce / Time Stamp etc. nie den gleichen Hash produzieren.

Damit wird sichergestellt, dass sich die Hashleistung auch bei mehreren Workern addiert, und niemals 2 Miner an der selben Aufgabe rechnen.

Muss ich dem Pool vertrauen dass er mit auch wirklich die Belohnung sendet

Wenn ihr Solo-Mining auf dem dem Public-Pool Projekt betreibt, bekommt ihr vom Pool alle 60 Sekunden ein komplett individuelles Block Template, welches in der Coinbase-Transaktion eure BTC-Adresse als Output für den Block-Reward enthält.
Ihr seid daher nicht auf das Vertrauen angewiesen, dass ein möglicher Block-Reward euch weitergesendet wird, weil der Reward mit der Coinbase-Transaktion bereits auf eure BTC-Adresse generiert wird.
Auch kann eure BTC-Adresse nicht durch eine andere Adresse ersetzt werden, weil sich sonst der Hash vom Block komplett verändern würde, und bei der geringsten Veränderung sofort ungütlig wäre.

Ihr müsst das übrigens nicht einmal blind glauben: Moderne AxeOS-Firmware (Bitaxe & Co.) bringt inzwischen einen eingebauten Coinbase-Decoder mit. Damit seht ihr direkt am Gerät, wie die Coinbase-Transaktion des aktuell bearbeiteten Templates aufgebaut ist – und könnt live verifizieren, dass wirklich eure eigene BTC-Adresse als Reward-Output eingetragen ist. So lässt sich mit einem Blick prüfen, dass der Pool euch im Erfolgsfall tatsächlich auszahlt und nicht heimlich eine fremde Adresse hinterlegt hat.

Dieses Vertrauen betrifft allerdings nur die Auszahlung. Eine ganz andere Frage ist, wer eigentlich bestimmt, welche Transaktionen überhaupt in den Block kommen – und genau da setzt das nächste Kapitel an.

Stratum V2 – das modulare Mining-Protokoll

Alles bisher Beschriebene – wie euer Miner Jobs erhält, Shares einreicht und mit dem Pool spricht – läuft klassischerweise über Stratum V1: ein simples, textbasiertes JSON-RPC-Protokoll, das seit Jahren der Arbeitstier-Standard ist. V1 hat aber zwei Schwächen: Es überträgt alles im Klartext (Pool-Adresse, eure BTC-Adresse, Jobs, Shares), und der Pool bestimmt vollständig, was in den Block kommt. Genau hier setzt Stratum V2 (SV2) an.

Wichtig vorweg, damit keine falschen Erwartungen entstehen: SV2 wurde in erster Linie für gepooltes Mining im grossen Massstab entworfen, nicht speziell für Solo-Mining. Und SV2 ist kein einzelnes, monolithisches Protokoll, sondern ein modularer Baukasten aus Sub-Protokollen – ihr nutzt nur die Teile, die ihr braucht. Das ist der Schlüssel zum Verständnis: Je nachdem, welche Bausteine zum Einsatz kommen, ändert sich, wie viel ihr dem Pool noch vertrauen müsst.

Stratum V1 vs. V2 – der direkte Vergleich

Bevor wir in die Details gehen, die wichtigsten Unterschiede auf einen Blick. Wichtig dabei: Mehrere SV2-Vorteile (vor allem die Trust-Minimierung) hängen am optionalen Job Declaration Protocol (JDP) – ohne JDP bleibt es beim alten Vertrauensmodell.

Die drei Sub-Protokolle

• Mining Protocol – der direkte Nachfolger von SV1 für die Job- und Share-Abwicklung. Statt textbasiertem JSON-RPC nutzt SV2 ein kompaktes Binärformat, was die Bandbreite drastisch senkt (rund 60 % weniger auf Pool-Seite) und die Latenz beim Job-Wechsel massiv reduziert. Das ist der einzige Baustein, den ihr für SV2 zwingend braucht.
• Job Declaration Protocol (JDP) – der eigentliche Game-Changer. Hier baut der Miner sein eigenes Block-Template gegen seinen eigenen Bitcoin-Node (über einen lokalen Job Declarator Client, JDC) und wählt selbst, welche Transaktionen hineinkommen. Der Pool betreibt dazu einen Job Declarator Server (JDS), der nur noch prüft, dass sein Payout-Output enthalten ist, und das Share-Accounting macht – er diktiert aber nicht mehr den Blockinhalt.
• Template Distribution Protocol (TDP) – liefert die nötigen Block-Informationen effizient direkt aus Bitcoin Core (per IPC statt ständigem getblocktemplate-Polling). Es ersetzt die alte, schwerfällige Template-Beschaffung und ist die Grundlage, damit JDP überhaupt sauber funktioniert.

Verschlüsselung: das Ende von Hashrate-Hijacking

SV2 bringt von Haus aus Verschlüsselung mit (das Noise_NX-Framework mit Pinning des statischen Pool-Public-Keys). Das verhindert Hashrate-Hijacking durch Man-in-the-Middle-Angriffe: Bei V1 kann jemand auf dem Netzwerkpfad zwischen euch und dem Pool die Klartext-Kommunikation abfangen und einen Teil eurer Shares auf einen fremden Pool umleiten (Schätzungen sprechen von bis zu ~2 % stehlbarer Rechenleistung), ohne dass ihr es merkt. Mit SV2 ist die Verbindung authentifiziert und verschlüsselt. Übrigens: Dieser gepinnte Public Key ist genau der Authority Key, den ihr beim Einrichten eines SV2-Pools (z. B. unseres Blitzpool) in eurem Miner hinterlegt.

Was SV2 für euch als Solo-Miner konkret bedeutet

Hier lohnt sich die saubere Unterscheidung, denn „SV2 = Dezentralisierung" ist eine verkürzte Aussage:

• SV2 ohne JDP (nur Mining Protocol): Ihr gewinnt Verschlüsselung und Effizienz – aber der Pool baut weiterhin das Block-Template. Bei der Frage, welche Transaktionen in den Block kommen, vertraut ihr dem Pool also genauso wie bei V1. Ohne JDP nimmt euch SV2 dieses Vertrauen nicht ab.
• SV2 mit JDP: Erst jetzt baut ihr selbst den Block und bestimmt den Inhalt – das ist der echte Hebel gegen Mining-Zentralisierung und Transaktionszensur. Dafür müssen aber zwei Bedingungen erfüllt sein: (1) der Pool, zu dem ihr minet, betreibt einen JDS, und (2) ihr betreibt einen eigenen Bitcoin-Node.

Vom Payout-Vertrauen (siehe Abschnitt oben) ist das unabhängig: Als Solo-Miner auf einem Public-Pool wird euer Reward ohnehin schon direkt über die Coinbase auf eure Adresse generiert – das ist bereits ohne SV2 vertrauenslos. JDP adressiert die andere Dimension: wer über den Blockinhalt entscheidet.

Adoption – Stand 2026

SV2 ist auf dem Vormarsch, aber noch nicht der Standard: Aktuell laufen schätzungsweise 15–20 % der Netzwerk-Hashrate über SV2. Braiins (Braiins OS+) bietet die reifste V2-Firmware inklusive Job Negotiation, DEMAND (DMND) war 2025 der erste vollständig auf SV2 gebaute Pool, und im Mai 2026 sind sieben grosse Pools (u. a. Foundry, Antpool, F2Pool) der SV2-Working-Group beigetreten. Bei der quelloffenen Hardware tut sich gerade richtig viel: Die NerdQaxe spricht SV2 bereits, und die Bitaxe spricht seit AxeOS 2.14 (veröffentlicht am 4. Juni 2026) ebenfalls SV2 – die Firmware-Implementierungen beider Geräte stammen von uns bei yourdevice. Unser Blitzpool bietet dazu die passende SV2-Gegenstelle für Solo-Miner.

Wenn ihr tiefer einsteigen möchtet, lest unsere ausführlichen Beiträge Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht und Stratum V2 und die Coinbase-Hoheit.

Solo-Pools in der Übersicht

CKpool

CKpool ist ein reiner Solo-Pool (277 Blöcke), der Code von ckpool ist frei verfügbar. Con Kolivas selbst geniesst grosses Vertrauen. Er war massgeblich an der Entwicklung von cgminer beteiligt. Die Oberfläche ist rudimentär und ohne Schnick-Schnack, dafür performant, stabil und die Konfiguration sehr einfach. Der Pool hat eine extrem hohe Uptime, der Block-Reward bzw. die Coinbase-Transaktion geht direkt an die eigene BTC-Adresse, ohne Umweg.

https://solo.ckpool.org/

Pool Fees
2% des Block-Rewards (exkl. Transaction Fees) gehen an ckpool an die BTC-Adresse bc1q28kkr5hk4gnqe3evma6runjrd2pvqyp8fpwfzu um den Pool zu betreiben und zur weiteren Pflege des ckpool-Codes beizutragen.

Settings

Pool URL:
stratum+tcp://eusolo.ckpool.org:3333
stratum+tcp://solo.ckpool.org:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

High-Difficulty Pool (für stärkere Miner) ab Work-Diff < 1'000'000 = 1'000K = 1M

Pool URL
stratum+tcp://eusolo.ckpool.org:4334
stratum+tcp://solo.ckpool.org:4334

Seit dem Update vom Juni 2023 verteilt ckpool alle 30 Sekunden (vorher alle 60 Sekunden) ein neues Block Template mit den aktuellsten Transaktion an die Miner.

Seit November 2024 betreibt Con Kolivas eusolo.ckpool.org auf einem eigenständigen Server in der EU. Der Pool hat eine deutlich geringere Latenz als solo.ckpool.org — die beiden Pools laufen unabhängig voneinander und können daher auch als Backup-Pools eingerichtet werden.

Pool Difficulty

CKpool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 10'000 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 20 Shares pro Minute – also alle 3 Sekunden 1 Share – überliefert wird.
Kommen mehr als 20 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 1.

Public Pool

Public Pool ist tolles Open-Source-Projekt mit attraktiven Statistiken.
Insbesondere für Miner mit Work-Diff < 1 bzw. Hashrate im Kilo- oder Megahash-Bereich geeignet, wie zB NerdMiner oder andere CPU-Miner.
Relativ jung und es gibt immer wieder Downtimes wegen Updates/Wartungsarbeiten.
Bisher wurde mit diesem Solo-Pool noch nie einen Block gefunden.

https://web.public-pool.io/ --> offizieller Public-Pool
https://blitzpool.yourdevice.ch/ --> Schweizer Public-Pool von yourdevice.ch betrieben.

Pool Fees
No Fees. 100% des Block-Rewards gehen an den Miner – seit Ende November 2023 auch für Miner mit mehr als 50 TH/s.

Settings

Pool URL
stratum+tcp://public-pool.io:21496
stratum+tcp://blitzpool.yourdevice.ch:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Pool Difficulty

Public Pool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 512 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 6 Shares pro Minute – also alle 10 Sekunden 1 Share – überliefert wird.
Kommen mehr als 6 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 0.00001

KanoPool

KanoPool ist sowohl Solo-Pool (0 Blöcke) als auch PPLNS-Pool (2434 Blöcke). Kano war ebenfalls an der Entwicklung von cgminer beteiligt. Deshalb blockiert KanoPool offenbar Miner, welche gegen die GPL-Lizenzbedingungen von cgminer verstossen, zB VNISH und Awesome. Ausserdem blockiert KanoPool IP-Adressen welche Hashrate von CPU-Miner oder GPU-Miner an den Pool schicken.
Die Konfiguration ist aufwendiger und für High-Difficulty-Worker ist diese teilweise echt mühsam und erfolgt nicht wie bei ckpool einfach über einen separaten Port.
Dafür bessere API-Schnittstelle, schönere Statistiken als ckpool, eine bessere Verteilung der Proxy-Server und geringere Gebühren (=Pool Fee) im Falle eines Block-Rewards (0.5%).

Jedoch hat man mit gesperrten IP-Adresse und extrem vielen rejected Shares zu gekämpft. Ausserdem wird der Block-Reward nicht direkt auf die eigene BTC-Adresse generiert, die Coinbase-Transaktion geht zuerst an die BTC-Adresse von Kano – eine Frage des Vertrauens.

https://kano.is/

Pool Fees
0.5% des Block-Rewards gehen an kano.

Settings

Pool URL
stratum+tcp://de.kano.is:3333

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

KanoPool ist nach der Registration standardmässig als PPLNS-Pool eingerichtet und muss aktiv auf Solo-Pool umgestellt werden. Dafür sind folgenden Voraussetzungen bzw. Schritte notwendig:

👉 The account must have been created in the last 2 hours
👉 You must not have pointed ANY miners at the account
👉 You must have verified the account email under Account >Verify
👉 You must have set a payout address under Account >Settings

☝️ You will not be able to change the account from Solo back to PPLNS

Pool Difficulty

KanoPool ist so konfiguriert, dass bei der ersten Verbindung einem Worker standardmässig die Work Diff = 8'190 zugewiesen wird.
Die Work-Diff wird so angepasst, dass im Durchschnitt 18 Shares pro Minute – also alle 3.3 Sekunden 1 Share – überliefert wird.
Kommen mehr als 18 Shares pro Minute wird die Work Diff vom entsprechenden Worker erhöht, kommen weniger wird die Work Diff gesenkt. Dabei ist das untere Limit, also die Minimum Work-Diff = 442.

High-Difficulty für stärkere Maschinen:

👉 Aktiviert in eurem Account unter Account > Solo die Option Allow high Difficulty.
👉 Erfasse auf Nicehash/MRR in eurer Pool-Konfiguration euren Worker mit entsprechenden Einstellungen, zB:
userXY.worker_highdiff
👉 Führt einen Test mit dem Poolverifikator durch, dadurch wird der Worker auf KanoPool im Account userXY unter Workers ersichtlich.
👉 Danach ändert ihr unter Workers > Mangagement beim gewünschten worker_highdiff, die Minimum Diff von 0 auf den erforderlichen Wert.
👉 Achtung: Der Poolverifikator wird zwar weiterhin einen Fehler melden: Poolschwierigkeitsgrad zu gering (vorausgesetzt=8190, minimum=500000), aber wenn die Minimum Diff entsprechend gesetzt wurde, wird der Auftrag trotzdem starten!

OCEAN Pool

Luke Dashj (Bitcoin Core developer) reaktiviert den Pool Eligius (2011-2017) unter dem Namen OCEAN.
Das Ziel ist, einen dezentralisierten, transparenten, zensurfreien, non-custodial Mining-Pool zu etablieren.
Weiter soll die Nutzung und Weiterentwicklung vonPoolschwierigkeitsgrad zu gering Stratum V2 vorangetrieben werden, ebenso ist die Intergration von Lightning-Auszahlungen (2024) geplant.
Das Belohnungssystem von OCEAN namens TIDES (Transparent Index of Distinct Extended Shares) gibt den Minern die Möglichkeit, noch vor dem Finden eines Blocks den genauen Betrag ihrer Bezahlung zu verifizieren. Die Miner werden direkt vom Bitcoin-Netzwerk in der Coinbase-Transaktion bezahlt.

https://ocean.xyz

Pool Fees
0% für die ersten 2 Monate des Betriebs, danach werden Gebühren eingeführt.

Settings

Pool URL

1️⃣ OCEAN, default (0% fee)
Enthält nur Transaktionen und relativ kleine Daten
mine.ocean.xyz:3334

2️⃣ Core+AntisMindestbetrag = 0.01048576 BTCpam (0% fee)
Enthält Transaktionen und begrenzten "Spam"
ordis.mine.ocean.xyz:3303

3️⃣ Core (2% fee)
Enthält Transaktionen und "Spam"
core.mine.ocean.xyz:3202

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Welches Protokoll spricht welcher Pool? (V1, V2, DATUM)

Zum Abschluss der Übersicht noch der vielleicht wichtigste Punkt: Welches Protokoll ein Pool tatsächlich spricht, entscheidet darüber, wie viel Kontrolle ihr über euren Block habt und wie viel ihr dem Pool vertrauen müsst.

• CKpool / eusolo.ckpool – Stratum V1. Bewährt und schlank, aber Klartext, und der Pool baut das Template.
• Public Pool – Stratum V1 (die quelloffene Referenz). Unser Blitzpool läuft auf einer modifizierten Public-Pool-Variante und bietet zusätzlich eine SV2-Anbindung für Solo-Miner an.
• KanoPool – Stratum V1.
• OCEAN – setzt nicht auf SV2, sondern auf das eigene DATUM-Protokoll. DATUM geht bei der Zensurresistenz sogar noch weiter als SV2: Der Pool ist für euer Template blind (er sieht nur Merkle-Zweige, nicht eure Transaktionsliste) und kann es daher technisch gar nicht ablehnen – und ihr broadcastet den gefundenen Block selbst von eurem eigenen Node. Zensur wird damit architektonisch unmöglich, nicht nur per Richtlinie.
• Braiins / DEMAND – volles Stratum V2 inklusive Job Declaration, primär aufs gepoolte Mining ausgelegt.

Kurz gesagt: Für Heim-Solo-Miner war V1 lange der einzige Realfall – doch das ändert sich gerade rasant: Die NerdQaxe spricht SV2 bereits, die Bitaxe spricht es seit AxeOS 2.14 (Release am 4. Juni 2026). SV2 und DATUM sind die zukunftsweisenden, dezentralisierenden Optionen, sobald auch euer Pool mitspielt.

Hashrate-Marktplatz

Nicehash ist kein Mining-Pool, sondern ein Hashpower-Marktplatz, ihr bietest also eure Hashrate auf dem Marktplatz an und werdet von Nicehash nach überlieferten Shares bezahlt (PPS = Pay per Share).
Mit und ohne KYC möglich.

https://www.nicehash.com/

Auszahlungen
PPS
Nicehash-Wallet: 0.00001 BTC (alle 4 Stunden), Payout fee 2%
BTC-Adresse: 0.001 BTC (wöchentlich), Payout fee 2% + 0.00001 BTC
BTC-Adresse: 0.100 BTC (täglich), Payout fee 2% + 0.00001 BTC
🔗 https://www.nicehash.com/support/mining-help/earnings-and-payments/can-i-get-paid-to-an-external-wallet-address

Settings (ohne KYC)

Pool URL
stratum+tcp://sha256asicboost.auto.nicehash.com:9200

Pool URL Alternative
stratum+ssl://sha256asicboost.auto.nicehash.com:443

Username
bc1qDoNotShareYourBTCAdressWithAnyBodyElse.workername

Password
x

Auszahlungsschwelle diverser Pools beim Reward Mining

Die meisten Pools haben eine vielfach höhere Auszahlungsschwelle und bei kleinen Beträgen schlagen sie eine Payout fee drauf.

Braiins
▪️Mindestbetrag = 0.0002 BTC
▪️Bei Auszahlungen ab 0.005 BTC entfällt die Payout fee von 0.0001 BTC

Lincoin
▪️Mindestbetrag = 0.001 BTC
▪️Bei Auszahlungen ab 0.001 BTC entfällt die Payout fee.

Nicehash
▪️Nicehash-Wallet (KYC): 0.00001 BTC (alle 4 Stunden), Payout fee 2%
▪️BTC-Adresse: 0.001 BTC (wöchentlich), Payout fee 2% + 0.00001 BTC
▪️BTC-Adresse: 0.100 BTC (täglich), Payout fee 2% + 0.00001 BTC

TIDES
Mindestbetrag = 0.01048576 BTC
Rewards die unter diesem Schwellenwert liegen, werden akkumuliert, bis der Schwellenwert überschritten wird, dann erfolgt die Auszahlung automatisch.

Beispiele

Wenn ihr zB. bei Nicehash kein KYC macht und somit auf eure eigene BTC-Adresse ausbezahlen wollt, müsst ihr mit einer Bitaxe mind. 44 Monate schürfen (ohne Berücksichtigung der steigenden Difficulty) bis ihr die Schwelle von 0.001 BTC erreicht🥸

Mining in der Schweiz

Für die Schweizer-Pleb-Miner, hier gibt es je nach Kanton teilweise ganz eindeutige Formulierungen:

Betrieb von Hardware-Infrastruktur:
Das aktive Betreiben von Hardware-Infrastruktur wie Mining oder Nodes wird im Grundsatz als selbständige Erwerbstätigkeit betrachtet. Daher müssen Kursgewinne und Erträge aus Kryptowährungen gewinnsteuerlich berücksichtigt werden. Im Gegenzug können Aufwände, die direkt mit dem Betrieb der Infrastruktur zusammenhängen, sowie eventuelle Kursverluste steuerlich geltend gemacht werden.

Wieso werde ich von manchen Pools geblockt obwohl ich einen Asic Miner habe

Das hat eben nichts mit ASIC oder nicht ASIC zu tun, sondern mit der sehr sehr geringen Hashrate. Ein Miner mit 1 MH/s benötigt gleich viel Ressourcen von einem Stratum-Proxy-Server wie ein Miner mit 200 TH/s. Das ist der Grund wieso CPU-Miner bereits vor Jahren von den meisten Pools geblockt wurden … Und Nicehash sowie der KanoPool möchten offensichtlich auch keine Miner mit weniger als 1 (?) TH/s …

Mining Hardware Optimieren Beispiel Anhand der Bitaxe

Das Overclocking und Undervolting von Mining-Hardware wie der Bitaxe können die Leistung und Effizienz eures Miners ein gutes Stück beeinflussen. Durch Anpassen von Taktfrequenz und Spannung könnt ihr die Hashrate steigern oder den Energieverbrauch senken. Auf einem Miner wie der Bitaxe sind die Auswirkungen hier eher begrenzt, aber auf grösserer Hardware mit vielen Hashboards und Mining Chips kann dies grössere Auswirkungen haben.

Overclocking bedeutet, die Taktfrequenz des ASIC-Chips zu erhöhen, um eine höhere Hashrate zu erzielen. Bei der Bitaxe kann dies über das Interface erfolgen, indem die Frequenz und die Kernspannung angepasst werden. Overclocking kann bis zu einem gewissen Teil auch ohne Spannungserhöhung durchgeführt werden. Dies ist effizienter, da ein Anstieg der Spannung den Vebrauch im Quadrat ansteigen lässt.

Undervolting reduziert die Betriebsspannung des Chips, was den Energieverbrauch senkt und die Effizienz steigert. Dies kann jedoch die maximale Taktfrequenz verringern. Es erfordert sorgfältiges Testen, um die optimale Balance zwischen Leistung und Effizienz zu finden. Häufig kann man aber die Taktfrequenz um ein paar MHz steigern, und dabei die Spannung um 1 bis 2 Schritte reduzieren, und bekommt bei gleicher Leistungsaufnahme mehr Hashrate.

Jede Hardware reagiert unterschiedlich auf Overclocking und Undervolting. Faktoren wie Chipqualität bzw. die Chipgüte und Kühlung spielen eine Rolle. Daher ist es wichtig, schrittweise Anpassungen vorzunehmen und die Stabilität sowie die Temperaturen zu überwachen. Für die Bitaxen sollte die Temperatur 70 °C nicht überschreiten, um eine optimale Leistung zu gewährleisten.

Für größere Mining-Geräte bietet BraiinsOS eine fortschrittliche Firmware mit Funktionen wie Autotuning, das Frequenz und Spannung für jeden Chip individuell anpasst. Dies ermöglicht eine effizientere Leistung und kann die Lebensdauer der ASICs verlängern.

Zusammenfassend können Overclocking und Undervolting die Mining-Performance verbessern, erfordern jedoch sorgfältige Anpassungen und Überwachung, um optimale Ergebnisse zu erzielen. Ausserdem lässt sich sagen, dass durch die Erhöhung der Spannung des Chips, meisst die Effizienz des Geräts stark nachlässt, deshalb sollten die Taktfrequenzen nur leicht angehoben werden, und im Idealfall die Spannung etwas abgesenkt werden.

Zum Bitaxe Tutorial gehts hier:

Erklärung zu den wichtigsten Realtime Logs

In den Logs eures Miners findet ihr viele Zahlen, wilde Wörter, und Buchstaben, damit ihr wisst um was es geht, haben wir die wichtigsten Logs für euch hier zusammengefasst:

₿ (32308602) asic_result: Nonce difficulty 282.96 of 1024.
⬇️ Die Nonce-Difficulty ist kleiner als die aktuelle Work-Difficulty, weshalb der Share nicht an den Pool übermittelt wird.

₿ (32308702) asic_result: Nonce difficulty 1329.45 of 1024.
⬆️ Die Nonce-Difficulty ist grösser als die aktuelle Work-Difficulty, weshalb der Share an den Pool übermittelt wird.

₿ (32308702) stratum_api: tx: {"id": 3414, "method": "mining.submit", "params": ["bc1q██████████████████████████████████████.bitaxeultra", "3b5cd3", "11000000", "65b7c4f1", "6ccc021a", "10c70000"]}
🆙 Der Share wird mit "mining.submit" an den Pool übermittelt.

Bei der Übermittlung eines Shares werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
id, userId, jobId, extraNonce2, ntime, nonce, versionMask

₿ (32308932) stratum_task: rx: {"id":3414,"error":null,"result":true}
ℹ️ Public Pool prüft den empfangenen Share auf Gültigkeit/Richtigkeit.

₿ (32308932) stratum_task: message result accepted
🆗 Public Pool bestätigt, dass der Share vom Pool akzeptiert wurde.

₿ (32301912) stratum_task: rx: {"id":null,"method":"mining.notify","params":["3b6238","708122a776e56322a64064232e31f3a7c5b8c7070002750f0000000000000000","02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff19034da20c5c7075626c69632d706f6f6c5c","ffffffff02503eea26000000001600149f82dd9e69e0008b7c5e16b2056aa679723492580000000000000000266a24aa21a9ed0b9310bb435af0c678e749e1cbd11a5eb1a75be6f3e7e31908c6131770f0a82800000000",["…"],"20000000","1704005a","65b7c52e",false]}
🆕 Public Pool verteilt mit "mining.notify" ein neues Block Template "3b6238" , entweder weil die Transaktionen aktualisiert wurden oder weil das Netzwerk einen neuen Block gefunden hat.

Bei der Übermittlung eines Block Template werden gemäss Stratum Protokoll die folgenden Werte übermittelt:
jobId, prevHash, coinbase part1, coinbase part2, merkle_branch, version, bits, timestamp, clear jobs

₿ (32302562) create_jobs_task: New Work Dequeued 3b6238
🆕 Nachdem das neue Block Template "3b6238" empfangen wurden, beginnt die Suche auf dieser neuen Grundlage.

₿ (260107) stratum_task: rx: {"params":[385],"id":null,"method":"mining.set_difficulty"}
₿ (260107) stratum_task: Set stratum difficulty: 385
↕️ Die Work-Difficulty wird für den Worker angepasst, damit die Zielvorgabe vom Pool betreffend Shares pro Minute erreicht wird.

Fazit

Die Welt des Minings ist komplex, aber zugleich faszinierend und voller Möglichkeiten. Mit dieser Mining-Bibel habt ihr die wichtigsten Grundlagen und Konzepte kennengelernt, um selbstständig ins Solomining einzusteigen. Angefangen bei der Funktionsweise der Blockchain über die Bedeutung von Hashrate, Shares und Difficulty bis hin zu den praktischen Aspekten wie Block Templates, Mining-Pools und der Anpassung eurer Hardware – dieses Wissen bildet ein solides Fundament für euren Erfolg.

Das Mining von Bitcoin ist weit mehr als nur ein technischer Prozess. Es ist ein Beitrag zu einem globalen, dezentralen Netzwerk, das Finanztransaktionen ohne zentrale Instanzen ermöglicht. Dabei könnt ihr nicht nur von finanziellen Belohnungen profitieren, sondern auch Teil einer Bewegung werden, die auf Freiheit und Unabhängigkeit setzt.

Denkt daran, dass Geduld und kontinuierliches Lernen essenziell sind. Die Technologie entwickelt sich stetig weiter, und der Wettbewerb wird immer anspruchsvoller. Doch mit der richtigen Einstellung, den richtigen Werkzeugen und der hier vermittelten Expertise seid ihr gut gerüstet, um euren Weg im Mining zu gehen.

Mögen eure Hashrate stark, eure Hardware stabil und eure Blöcke erfolgreich sein! Viel Erfolg und Spaß beim Mining! 🚀

Lust auf's Solomining? Schaut mal hier vorbei:

https://yourdevice.ch/produkt-kategorie/btc-nodes-zubehoer

The post Die kleine Bitcoin Solo Mining Bibel appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.

Dank des eingebauten WiFi-Mikrocontrollers (ESP32-S3-WROOM-1) lässt sich die Bitaxe einfach in eures Netzwerk integrieren und mit eurem bevorzugten Mining-Pool verbinden. Wir schauen uns in diesem Artikel die Einrichtung und Anwendung der Bitaxe an. Das BitaxeOS ist OpenSource, und der Sourcecode kann auf Github betrachtet werden.

Die Bitaxen sind echte Vorreiter, da sie vollständig montiert und einsatzbereit geliefert werden. So wird der Einstieg in das Bitcoin-Mining zu einem Kinderspiel. Dank der intuitiven Benutzeroberfläche von AxeOS könnt ihr sofort mit dem Mining beginnen, ohne euch mit komplexen Konfigurationen auseinandersetzen zu müssen.

Welche Bitaxe passt zu mir? Die Modelle im Überblick (2026)

Die Bitaxe gibt es in mehreren Varianten, die sich vor allem im verbauten ASIC-Chip und damit in Hashrate und Effizienz unterscheiden. Aktuell (Stand 2026) ist die Gamma mit dem modernen BM1370-Chip das Flaggschiff und die effizienteste Einzelchip-Variante. Hier die gängigen Modelle im Vergleich:

Für die meisten Einsteiger ist die Bitaxe Gamma die beste Wahl: höchste Hashrate pro Chip bei der besten Effizienz. Wer mehrere Geräte leise und sparsam betreiben möchte („Swarming“, dazu unten mehr), fährt mit der Supra gut. Die folgende Einrichtung ist bei allen Modellen praktisch identisch, da sie alle dieselbe AxeOS-Firmware nutzen.

Vorbereitungen und Voraussetzungen

Ihr benötigt eigentlich nur einen Platz mit möglichst gutem 2.4Ghz WLAN Empfang. 5Ghz unterstützt das Gerät leider nicht. Die Reichweite ist bei 2.4Ghz meisst auch höher, und die Verbindung ist zuverlässiger und stabiler, wenn auch nicht so schnell, und von den Latenzen halt auch etwas höher.

Des weiteren benötigt ihr zudem ein Smartphone um die erste Verbindung zur BitAxe herzustellen.

Einrichtung und Anwendung der Bitaxe

Gerät anschließen

Schließt das Netzteil an die Bitaxe an und verbindet es mit einer Stromquelle. Es gibt keinen An- und Ausschalter. Das Gerät startet automatisch, sobald es mit Strom versorgt wird.

Verbindung zum Access Point herstellen

Der erste Start erfolgt über das WLAN Access Point des Geräts.

Sucht in eurem WLAN nach dem Access Point der Bitaxe. Der Name des Netzwerks (SSID) ist auf dem Gerät Display zu sehen.

Verbindet euch mit diesem WLAN. Es ist kein Passwort erforderlich, da es sich um einen offenen Access Point handelt.

Konfiguration über Captive Portal

Nachdem ihr euch mit dem Access Point verbunden habt, öffnet sich automatisch ein Captive Portal (ähnlich wie in Hotels oder öffentlichen Netzwerken).

Geht in den Reiter Network des Geräts. Gebt hier die SSID eures Heim- oder Unternehmensnetzwerks sowie das Passwort ein, um die Bitaxe in euer WLAN zu integrieren. Speichert die Einstellungen und startet das Gerät über das Interface ganz unten neu.

Hinweis: Ab Version 2.6.1 ist es neu das WLAN über die Lupe zu suchen, das Gerät scannt dann automatisch alle WLANs, und ihr könnt das richtige dann einfach mit einem klick auswählen, anstatt die SSID manuell einzugeben.

Zugriff auf die Benutzeroberfläche

Nach dem Neustart verbindet sich die Bitaxe mit eurem WLAN. Um auf das Dashboard zuzugreifen, ermittelt die IP-Adresse des Geräts (entweder über den Router oder einen IP-Scanner)

Öffnet euren Browser und gebt die IP-Adresse ein. Für das Webinterface ist kein Passwort erforderlich.

Pool- und Wallet Konfiguration

Im Dashboard in den Poolsettings findet ihr die "Pool-Einstellungen".

Pool ändern: Ihr könnt unseren gebührenfreien Schweizer Pool `blitzpool.yourdevice.ch` auf Port 3333 verwenden. Tragt diese Informationen in die entsprechenden Felder ein. Ihr könnt natürlich jeden anderen Pool eurer Wahl nehmen.

Wallet-Adresse: Löscht die Standard-Bitcoin-Adresse und fügt eure eigene Bitcoin-Adresse ein, um sicherzustellen, dass die Mining Belohnungen direkt an euch ausgezahlt werden. Nutzt eine Bitcoin Adresse von einer Hard- oder Softwarewallet eurer Wahl. Wählt ein Passwort damit ihr eure Statistiken auch auf https://blitzpool.yourdevice.ch einsehen könnt.

Hinter eure BTC Adresse könnt ihr einen Namen anhängen. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine bestimmte Gruppe aus Minern kann damit erstellt werden. Das geht indem ihr hintere eure BTC Adresse einen Namen anhängt, separiert mit einem Punkt. Somit lassen sich bestimmte Worker Gruppen erstellen. Eine Kombination aus Minern könnte zum Beispiel so aussehen:

bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.bitaxe heissen, eine weitere zum Beispiel
bc1qnu7xxxxxxxxxxxxxxxxxxxxxxptez73ch4.nerdminer

So lassen sich die Geräte voneinander trennen. Der Reward geht natürlich immer noch an die selbe BTC-Adresse.
In den Pool Statistiken tauchen die Geräte dann gruppiert und den jeweiligen Workernamen auf.

Damit die Einstellungen wirksam werden, müsst ihr unten auf Save klicken, und dann links in der Einstellungsleiste Restart auswählen.

Fallback Pool definieren: Seit dem Update auf die Version 2.3.0 könnt, oder ist ein Fallback Pool definiert. Falls der Primary Pool ausfällt, mint die Bitaxe im automatisch im Fallback Pool weiter.

Stratum V1 oder V2

Neu könnt ihr in den Pool-Einstellungen zwischen Stratum V1 (SV1) und dem moderneren Stratum V2 (SV2) wählen. SV2 verschlüsselt die Verbindung zwischen Miner und Pool (Schutz vor Man-in-the-Middle-Angriffen), kommt mit deutlich weniger Datenverkehr aus und erlaubt es Minern perspektivisch, ihre Blockvorlage selbst zu bestimmen – ein wichtiger Schritt für mehr Dezentralisierung im Bitcoin-Netzwerk. Die Hintergründe haben wir im Beitrag Stratum V2 – Warum das Bitcoin-Mining ein neues Protokoll braucht ausführlich erklärt.

Für SV2 benötigt ihr neben Host und Port zusätzlich den Authority Key (den Public Key des Pools). Zwei empfehlenswerte SV2-Pools:

• Blitzpool (unser Schweizer Solo-Pool, 0 %) – Host blitzpool.yourdevice.ch, Authority Key:
  9bCoFxTszKCuffyywH5uS5o6WcU4vsjTH2axxc7wE86y2HhvULU
  Die vollständigen Verbindungsdaten findet ihr auf blitzpool.yourdevice.ch/stratum-v2.
• Braiins Pool (gepoolt, die Entwickler von Stratum V2) – Host stratum-v2.braiins.com, Port 3336, Authority Key:
  u95GEReVMjK6k5YqiSFNqqTnKU4ypU2Wm8awa6tmbmDmk1bWt
  Aktuelle Werte stets in der offiziellen Braiins-Anleitung prüfen.

Übernehmt eure Auswahl wie gewohnt mit SAVE und einem anschliessenden RESTART. Im Zweifel funktioniert SV1 nach wie vor problemlos – SV2 ist die zukunftssichere, aber optionale Wahl.

Welchen Mining-Pool für die Bitaxe wählen?

Mit einer Bitaxe minet man in der Regel solo – ihr nehmt also an einer Art Lotterie teil: Die Chance, einen ganzen Block zu finden, ist klein, dafür erhaltet ihr im Erfolgsfall die komplette Block-Belohnung. Dass das kein reines Märchen ist, zeigt der erste mit einer Bitaxe Supra solo gefundene Block #887.212 im März 2025. Für das Solo-Mining haben sich diese Pools etabliert:

• Blitzpool – unser eigener Schweizer Public-Pool (auf Basis der quelloffenen Public-Pool-Software). 0 % Gebühren, übersichtliche Statistiken und dank Serverstandort Schweiz niedrige Latenz für CH/EU. Stratum: stratum+tcp://blitzpool.yourdevice.ch:3333
• eusolo.ckpool.org – die EU-Variante von Con Kolivas’ ckpool (eigener Server in der EU seit Ende 2024, dadurch deutlich geringere Latenz als das originäre solo.ckpool.org). 2 % Gebühr im Erfolgsfall.
• Public Pool – der originale, quelloffene Public-Pool. 0 % Gebühren und sogar selbst hostbar – genau die Software, auf der auch unser Blitzpool läuft.

Bevor ihr euch realistische Erwartungen setzt, lohnt sich ein Blick in unsere Beiträge Solo Mining – die grössten Fehlannahmen und Die kleine Bitcoin Solo Mining Bibel. Wer lieber regelmässige Kleinauszählungen statt der Lotterie möchte, findet im Artikel Bitcoin Mining Pool die Alternative.

Mining starten

Der Miner startet automatisch, sobald die Pooleinstellungen korrekt eingegeben und gespeichert wurden sind. Seht ihr keine Hashrate, stimmt was mit euren Pool-Einstellungen nicht.

Unten findet ihr noch Informationen zum aktuellen Stromverbrauch, der ASIC Spannung, der Lüfterdrehzahl und der aktuellen Temperatur des Chips

Leistungsoptimierung

Passt die Mining-Einstellungen wie Hashrate, Spannung und Lüftergeschwindigkeit an. Es ist ratsam, zunächst mit den Standardeinstellungen zu beginnen. Es sei gesagt dass man durch Overclocking das Gerät beschädigen kann, und dass man dadurch natürlich jedliche Garantien und Gewährleistungen verliert. Die Temperaturen sollten im Auge behalten werden, es empfiehlt sich, andere Kühlkörper und Lüfter als die Standardlüfter zu verwenden. Der Noktua Lüfter eignet sich auch eher weniger für das Übertakten, da dieser von Haus aus leiser arbeitet, und nicht besser.

Speichert die Einstellungen und startet die Bitaxe anschliessend neu, um eure Einstellungen zu übernehmen.

Advanced Overclocking

Fügt ihr im Browser am Ende der Adresse ?oc= ein, öffnet sich der erweiterte Overclocking Modus. Hier können die Werte manuell und frei gewählt werden. Es sind nahezu keine grenzen gesetzt. Bitte achtet besonders drauf was hier ihr eingebt. Ausversehen 1.5v Asic Spannung eingegeben führen dann ziemlich schnell zum Tot des Asic Chips.

Beispiel:

👉 192.168.1.21/#/settings
👉 192.168.1.21/#/settings?oc=

Monitoring und Wartung

Beobachte die Temperatur und die Hashrate im Dashboard. Der Asic Miner taktet automatisch herunter, sollte die Temperaturen über 65° steigen. Alles bis zu 65° ist vollkommen in Ordnung.

Reinigt ausserdem das Gerät auch regelmäßig, um Überhitzung durch Staubansammlungen zu verhindern.

Sicherheit und Updates

Haltet die Firmware des Geräts auf dem neuesten Stand, um optimale Leistung und Sicherheit zu gewährleisten.

Klickt dafür auf esp-miner.bin und ladet die Firmware herunter, und für das Web-UI auf www.bin. Danach wählt ihr unter Update Firmware Browse Button und wählt die esp-miner.bin und bei Update Webseite die www.bin. Das Gerät läd die Firmware automatisch, und muss danach neu gestartet werden.

Swarming

Ihr könnt im Tab Swarm eure Geräte verbinden, um sie jeweils von einer Bitaxe aus alle zu konfigurieren. Fügt dafür einfach unter AxeOS Device IP die IP Adresse der anderen Miner hinzu:

Bitaxe herunterfahren

Um die Bitaxe herunterzufahren, müsst ihr nichts anderes tun, als das Stromkabel zu trennen. Das tut der Bitaxe keinen Schaden, und wird auch das Betriebssystem nicht beschädigen.

Bitaxe zurücksetzen und wieder in den Acess Point Modus bringen

Geht einfach auf das Web-UI der jeweiligen Bitaxe, und löscht eure WLAN Daten wie die SSID und das WLAN Passwort. Startet das Gerät anschliessend neu. Das Gerät wird dann wieder in den AP-Modus gehen. Bei einem Verkauf eurer Bitaxe, löscht ihr am besten gleich noch sämtliche Einstellungen wie den Pool, eure BTC-Adresse, und das Passwort.

Firmware neu Flashen

Falls irgendwas mal total schief gegangen ist, und die Bitaxe nicht mehr reagiert, hilft es, die Firmware neu zu flashen. Auch kann es vorkommen, dass der Overheating Modus durch ein Missgeschickt aktiviert wird, wenn sich das Gerät noch nicht mit dem WLAN verbunden hat. In diesem Fall agiert die Bitaxe nicht mehr als Access Point und der Overheating Modus kann nicht deaktiviert werden.

Besucht den Link für dem Online Firmwareflasher:

https://bitaxeorg.github.io/bitaxe-web-flasher

Schliesst eure Bitaxe an den Strom, und verbindet die Bitaxe mit einem USB-C Kabel mit eurem Rechner.

Klickt danach auf Connect, und wählt die ttyUSB Verbindung. Wählt das richtige Gerät, und das richtige Board aus, und beginnt das flashen der Firmware mit Start Flashing. Die Firmware wird nun auf eure Bitaxe geflasht. Die Bitaxe führt, danach einen Funktionscheck durch. Danach müsst ihr die Bitaxe noch neu starten, und sie befindet sich wieder im AP Modus.

Fazit

Mit der Bitaxe seid ihr bestens gerüstet, um in die Welt des Bitcoin-Minings einzutauchen. Die Einrichtung ist dank der benutzerfreundlichen Bedienoberfläche und einfachen Netzwerkanbindung schnell erledigt. Ob ihr ein erfahrener Miner oder Neueinsteiger seid – die Flexibilität und Leistungsfähigkeit dieses Geräts ermöglichen es euch, das Beste aus eurem Mining-Erlebnis herauszuholen. Sobald die Konfiguration abgeschlossen ist und der Miner korrekt läuft, könnt ihr entspannt zurücklehnen, während die Bitaxe effizient und zuverlässig ihre Arbeit erledigt. Viel Erfolg!

Falls ihr auf der Suche nach 'ner Bitaxe seid, schaut mal bei uns im Shop vorbei!

Sucht ihr nach mehr Infos und Theorie zum Mining, dann haben wir die kleine Bitcoin Mining Bibel für euch:

Habt ihr Lust unserem Mining Pool beizutreten? Unser Ziel ist es, in der Schweiz einen Block zu finden. Mit den Jungs aus der Schweiz und Plebs aus verschiedenen Ländern haben wir bereits gut Hashrate zusammen!

Nehmt euren Miner in die Hand, und konfiguriert diesen auf unseren Pool:

Stratum Host: blitzpool.yourdevice.ch
Port: 3333
Alternativer Port: 4444

Wir betreiben einen stark modifizierten Public-Pool Fork der welcher extrem erweitert worden ist, und sich auch fürs Mining mit Freunden eignet. Somit habt ihr, wenn ihr zusammen auf einer Adresse schürft, eure Worker komplett im Überblick.

Pool UI: https://blitzpool.yourdevice.ch

Häufige Fragen zur Bitaxe

Lohnt sich Solo-Mining mit einer Bitaxe?

Finanziell betrachtet ist es eine Lotterie: Die Wahrscheinlichkeit, mit einem einzelnen Gerät einen Block zu finden, ist sehr gering. Viele betreiben eine Bitaxe daher aus Überzeugung – um das Netzwerk zu dezentralisieren, zu lernen und die Chance auf den „Lottogewinn“ mitzunehmen – statt als zuverlässige Einnahmequelle.

Welche Bitaxe eignet sich für Einsteiger?

Die Bitaxe Gamma mit BM1370-Chip ist aktuell die Empfehlung: beste Effizienz (~15 J/TH) und höchste Hashrate aus einem einzelnen Chip. Sie kommt fertig montiert und läuft direkt mit der AxeOS-Firmware.

Wie viel Strom verbraucht eine Bitaxe?

Je nach Modell und Taktung etwa 12 bis 21 Watt. Eine Supra liegt um die 12 W, eine Gamma bei rund 15–21 W. Im „PowerSave“-Betrieb lässt sich der Verbrauch zugunsten der Effizienz weiter senken.

Ist die Bitaxe wirklich Open Source?

Ja. Sowohl das Hardware-Design als auch die Firmware AxeOS (ESP-Miner) sind quelloffen und auf GitHub einsehbar. Das ist einer der grössten Vorteile gegenüber herkömmlichen Closed-Source-Minern.

Zuletzt aktualisiert im Juni 2026 – Modellübersicht (inkl. Gamma BM1370), Pool-Empfehlungen und FAQ ergänzt.

The post Bitaxe Miner Einrichtung und Anwendung appeared first on yourdevice.ch - Deine Anlaufstelle für Linux, OpenSource Software und Co.