Braucht Man Einen Pool zum Solo-Mining?

Man kann ein Mining-Gerät nicht direkt auf einen Bitcoin-Node richten und minen. Ein ASIC spricht Stratum, ein Node spricht RPC, und etwas muss dazwischensitzen, Block-Templates bauen und Arbeit verteilen. Solo CKPool sagt das auf seiner eigenen Startseite. Die eigentliche Frage ist also nicht Pool oder kein Pool. Es ist die Frage, wessen Pool-Software auf wessen Hardware von wem gewartet wird.

Diese Umrahmung ist wichtig, weil sie eine Loyalitätsfrage in eine technische verwandelt. Hier sind die drei echten Architekturen, was jede davon tatsächlich bietet, und die Ausfallmodi, die Setup-Anleitungen meist in einer Fußnote erwähnen.

Wichtigste Erkenntnisse

• Es gibt keine Konfiguration ohne Pool-Software. Self-Hosting bedeutet, sie selbst zu betreiben, nicht darauf zu verzichten.
• Der eigene Node verbessert die Chancen nicht. Chancen hängen nur von Hashrate und Schwierigkeit ab. Self-Hosting kann die effektiven Chancen durch Ausfallzeiten und Stale Work senken.
• Was es bietet, ist Template-Kontrolle — die Entscheidung, welche Transaktionen in den Block kommen. Das ist eine echte und sinnvolle Sache.
• Stale Work ist das Hauptrisiko, und die DATUM-Dokumentation benennt es explizit: Ohne prompte Neue-Block-Benachrichtigungen hasht die Hardware für nichts.
• Gehostete Pools betreiben mehrere geografische Endpunkte mit automatischem Failover. Der heimische Node hat einen Endpunkt: die heimische Internetverbindung.
• DATUM ist der Mittelweg: eigene Templates, fremde Share-Buchhaltung. Beta-Software, nur Linux, nur Bitcoin.

Warum man nicht direkt auf einen Node minen kann

Das überrascht viele, und es lohnt sich, genau darüber zu sein, weil alles andere daraus folgt.

Die Aufgabe eines Bitcoin-Nodes ist Validierung und Weiterleitung. Er bietet eine RPC-Schnittstelle, darunter getblocktemplate, die einen Kandidatenblock zurückgibt: die Header-Felder, einzuschließende Transaktionen und die Regeln. Er verteilt keine Arbeit an Miner, verfolgt keine Einreichungen, passt die Schwierigkeit pro Gerät an und setzt keine eingereichte Share zu einem Block zusammen.

Der ASIC spricht Stratum. Er erwartet, dass ein Server ihm einen Job schickt, die Share-Schwierigkeit mitteilt, Einreichungen akzeptiert und benachrichtigt, wenn sich der Job ändert.

Dazwischen sitzt ein Stratum-Server. Solo CKPool beschreibt sich auf seiner eigenen Seite so: kein Pool trotz des Namens, sondern ein Dienst, der existiert, weil man nicht direkt auf einen Bitcoin-Core-Node minen kann. Das ist die genaue Beschreibung jeder Option auf dieser Seite, einschließlich der selbst gehosteten.

Die drei Architekturen

Keine davon ist der „echte” Weg zum Solo-Mining. Es sind verschiedene Verteilungen von Kontrolle und Verantwortung, und die richtige hängt davon ab, von welcher man tatsächlich mehr will.

Was Self-Hosting wirklich bietet

Wenn das die gewünschten Dinge sind, ist Self-Hosting die richtige Antwort, und nichts Folgendes sollte davon abbringen.

Was es kostet — aus der Dokumentation

Jeder Punkt hier kommt aus den eigenen Anforderungen der Projekte oder dem Verhalten, vor dem sie warnen, nicht aus Spekulation.

1. Stale Work ist das echte Risiko

Wenn ein neuer Block irgendwo im Netzwerk gefunden wird, wird jedes auf dem vorherigen aufbauende Template sofort wertlos. Der Stratum-Server muss das innerhalb von Millisekunden erfahren und neue Arbeit senden, sonst hasht die Hardware weiter gegen einen toten Job.

Die DATUM-Gateway-Dokumentation spricht das direkt an und instruiert Betreiber, ihren Node so zu konfigurieren, dass er Block-Benachrichtigungen speziell an das Gateway sendet, um Stale Work zu vermeiden. Das ist eine Zeile in bitcoin.conf und ein Abhängigkeitspaket. Falsch konfiguriert, bricht nichts sichtbar: Das Dashboard zeigt eine gesunde Hashrate, Temperaturen sehen gut aus, und man produziert nichts.

2. Failover ist nicht kostenlos

Solo CKPool betreibt Endpunkte in USA, Europa, Asien und Ozeanien, wählt automatisch den mit der niedrigsten Latenz und übernimmt bei Ausfall. Diese Redundanz ist unsichtbar, wenn sie funktioniert.

Der selbst gehostete Stack hat einen Endpunkt. Wenn der Node abstürzt, der Strom flackert oder der ISP eine schlechte Stunde hat, haben Miner nirgendwo hinzugehen, es sei denn, man konfiguriert einen Fallback — und der einzig vernünftige Fallback ist ein gehosteter Pool.

3. Die Maschine ist eine echte Maschine

Die angegebenen Anforderungen des DATUM-Gateways sind: Linux-System, vollständig synchronisierter Bitcoin-Fullnode (Knots empfohlen), schneller Speicher, stabile Verbindung, CPU für verzögerungsfreie Block-Validierung und ca. 1 GB RAM zusätzlich zu den Node-Anforderungen. Darunter liegt ein Fullnode: Hunderte Gigabytes Speicher und eine anfängliche Synchronisierung, die Tage dauert.

Das ist kein Exotisches. Es ist aber auch ein zweites Gerät, das dauerhaft läuft, Strom verbraucht, Updates benötigt und Aufmerksamkeit beansprucht. Bei einem 15-W-Miner und einem 40-W-Node zu seiner Unterstützung ist der Node nun der größere Teil der Stromrechnung.

4. Konfigurationsfehler sind lautlos und teuer

Das DATUM-Setup erfordert das Reservieren von Block-Platz für die Generation-Transaktion, und die Dokumentation ist explizit, dass ohne diese Reservierung die Arbeit keine Belohnungsaufteilung unterstützen kann. Das ist eine Konfigurationszeile, deren Fehlen man im schlimmsten Moment entdecken würde.

5. Beta-Software, schmale Plattform

DATUM Gateway ist bei v0.4.1beta, unterstützt nur Linux und nur Bitcoin. Eigene Release-Notes sagen, dass andere Betriebssysteme funktionieren können, aber auf eigene Gefahr. Das ist ehrliche Kennzeichnung des Projekts.

Für die vier SHA-256-Chains jenseits von Bitcoin ist DATUM keine Option. Ein vollständig selbst gehosteter ckpool-Stil-Stack kann sie bedienen, aber dann betreibt man einen Node pro Chain.

6. Man ist das Operations-Team

Das quantifiziert niemand und spürt jeder schließlich. Die Uptime eines gehosteten Pools ist jemandes Job. Die Uptime des eigenen Nodes ist etwas, an das man sich erinnert zu prüfen, bis zu der Woche, in der man auf Reisen ist.

Die Uptime-Arithmetik

Chancen skalieren linear mit der Zeit, die mit valider Arbeit gehashed wird. Ein Gerät, das offline ist oder an einem veralteten Template arbeitet, kauft in dieser Zeit nichts. Ausfallzeit ist also eine direkte prozentuale Reduzierung der effektiven Hashrate.

Der Vergleich ist nicht perfekt, aber als Faustregel nützlich: Wenn Self-Hosting mehr als ein oder zwei Prozent Uptime kostet, war die vermiedene Gebühr die günstigere Option.

Wer selbst hosten sollte

Diese Optionen schließen sich nicht gegenseitig aus. Das robusteste Heimsetup ist meist eine Mischung: selbst gehosteter Primär wo Souveränität wichtig ist, gehosteter Fallback konfiguriert, damit ein Node-Problem nicht zu toter Hardware wird. Jedes AxeOS-Gerät unterstützt einen Fallback-Stratum-Host, und das Konfigurieren kostet nichts.

Was auf jeden Fall zählt

Zwei Dinge überleben das ganze Argument.

Wer das Template baut, entscheidet, was Bitcoin bestätigt. Wenn Dezentralisierung der Grund für Solo-Mining ist, ist das der Hebel, und er ist über DATUM verfügbar, ohne den gesamten Stack selbst betreiben zu müssen.

Wer die Belohnung hält, entscheidet, ob man sie bekommt. Ein Block, der direkt im Coinbase an eine selbst kontrollierte Adresse ausgezahlt wird, braucht keinen Anspruch, keine Auszahlung und kein Vertrauen. Das gilt für ein selbst gehostetes Setup wie für einen nicht-verwahrenden gehosteten Pool. Deshalb setzt unser Leitfaden zur Pool-Auswahl verifizierbare nicht-verwahrende Auszahlung an zweite Stelle.

Zwischen diesen beiden ist die Frage, wessen Maschine den Stratum-Server betreibt, eine Operations-Frage, keine Prinzipienfrage. Die Antwort mit der ehrlichen Einschätzung der eigenen Uptime geben, nicht mit der, die man gerne wahr hätte.