Solo + Friends — Ausführliche Anleitung (Deutsch)

Diese Anleitung verwandelt deinen lokalen dvb-WarpPool in einen Pool, den deine Freunde von zu Hause aus mit ihren Minern über das Internet erreichen können — verschlüsselt über TLS, mit echtem Let’s Encrypt-Zertifikat (kein “Insecure Mode” am Miner nötig).

Zeitbedarf: ca. 15-20 Minuten Vorausgesetzt: WarpPool läuft schon lokal auf deinem Mac, Fritz!Box ist dein Router

Was wir hier eigentlich machen

Das Problem: Bitaxe-Firmware mit “Bundled CA”-Modus akzeptiert nur Zertifikate von echten Certificate Authorities (Mozilla Root Bundle). Dein aktuelles Self-signed Cert wird abgelehnt. → Wir brauchen ein echtes Cert.

Echte Certs gibt’s gratis bei Let’s Encrypt — aber nur für einen DNS-Namen (nicht für eine bloße IP-Adresse). Du brauchst also einen “Namen für deinen Mac im Internet”. Das macht DuckDNS: gratis Subdomain <wunschname>.duckdns.org, die immer auf deine aktuelle Heim-IP zeigt.

Was du am Ende hast:

<sub>.duckdns.org zeigt auf deine Fritz!Box-IP (auch wenn sich die ändert)
Fritz!Box leitet Port 3334 auf deinen Mac weiter
Mac antwortet mit echtem Cert für <sub>.duckdns.org
Bitaxe vertraut dem Cert (weil Let’s Encrypt im Bundle ist)
→ Externe Miner können sich verschlüsselt verbinden

Phase 1 — DuckDNS-Account anlegen

Zeit: 2 Min.

Browser auf https://www.duckdns.org/ öffnen.
Oben rechts mit GitHub, Twitter, Reddit oder Google einloggen (am einfachsten GitHub falls du dort schon einen Account hast).
Du landest auf der Übersichtsseite. Oben siehst du:
- Token: eine 32-stellige Hex-Zahl wie a1b2c3d4-e5f6-...
- Darunter ein leeres Feld “sub domain” mit “add domain”-Button daneben.
Wunschname eintippen (z.B. warppool-oliver oder oliver-pool — was dir gefällt, muss noch frei sein) → “add domain” klicken.
Die Subdomain erscheint in der Liste. Notiere dir:
- Subdomain (nur das warppool-oliver-Teil, ohne .duckdns.org)
- Token (oben rechts, 32 Hex-Zeichen)

Beides brauchst du in Phase 2 und Phase 4.

Tipp: Den Token nicht in Slack/Discord posten. Wer ihn hat, kann deine Subdomain auf eine fremde IP umlenken.

Phase 2 — Fritz!Box: DDNS einrichten

Zeit: 3 Min.

DDNS = Dynamic DNS. Deine Fritz!Box ruft alle paar Minuten DuckDNS auf und sagt “die IP für warppool-oliver ist jetzt X”. Damit zeigt deine Subdomain immer auf dein Zuhause, auch wenn dein Provider die IP wechselt.

Browser auf http://fritz.box/ oder http://192.168.178.1/.
Einloggen mit deinem Fritz!Box-Passwort.
Linkes Menü: Internet → Freigaben.
Reiter DynDNS wählen.
Häkchen bei “DynDNS benutzen” setzen.
DynDNS-Anbieter: “Benutzerdefiniert” wählen.
Update-URL: exakt diese Zeile einfügen (Subdomain + Token durch deine ersetzen):
```
https://www.duckdns.org/update?domains=<DEINE_SUBDOMAIN>&token=<DEIN_TOKEN>&ip=<ipaddr>
```
Beispiel (mit Beispiel-Werten):
```
https://www.duckdns.org/update?domains=warppool-oliver&token=a1b2c3d4-e5f6-7890-abcd-ef1234567890&ip=<ipaddr>
```
Wichtig: Das <ipaddr> am Ende ist ein Platzhalter — den lässt du exakt so stehen. Die Fritz!Box ersetzt das beim Senden mit deiner aktuellen IP.
Domainname: <DEINE_SUBDOMAIN>.duckdns.org (z.B. warppool-oliver.duckdns.org).
Benutzername: irgendwas Beliebiges (z.B. none) — DuckDNS prüft nur den Token.
Kennwort: auch irgendwas (z.B. none).
“Übernehmen” klicken.

Test: Im Terminal auf dem Mac:

dig +short warppool-oliver.duckdns.org @8.8.8.8

Sollte deine öffentliche IP zurückgeben (dieselbe wie unter https://www.whatismyip.com/ angezeigt). Falls leer: 30 Sekunden warten, nochmal versuchen — Fritz!Box muss erst einmal updaten.

Phase 3 — Fritz!Box: Port 3334 freigeben

Zeit: 3 Min.

Externe Miner verbinden sich zu warppool-oliver.duckdns.org:3334 → landen bei deiner Fritz!Box → die muss wissen wohin damit (= deinem Mac).

Fritz!Box → Internet → Freigaben → Reiter Portfreigaben.
Klicke “Gerät für Freigaben hinzufügen” (oder bei einem bereits vorhandenen Gerät auf “Bearbeiten”).
Wähle dein Mac-Gerät aus (sollte als hostname-irgendwas oder MacBook-Pro etc. erscheinen — IP 192.168.178.10).
Klicke “Neue Freigabe” → “Portfreigabe”.
Anwendung: “Andere Anwendung”.
Bezeichnung: WarpPool TLS Stratum (für deine Übersicht).
Protokoll: TCP.
Port an Gerät: 3334
Port extern gewünscht: 3334
Häkchen bei “Freigabe aktivieren”.
“OK” → dann “Übernehmen”.

Test: Auf einem externen Gerät (z.B. dein Handy mit ausgeschaltetem WLAN, also über Mobilfunk):

nc -zv warppool-oliver.duckdns.org 3334

Sollte Connection to warppool-oliver.duckdns.org port 3334 [tcp/*] succeeded! zeigen.

Falls das nicht geht von extern aber vom Mac selbst funktioniert: NAT-Loopback-Problem der Fritz!Box (kennt manche Modelle). Externe Tests aber von extern machen.

Phase 4 — Setup-Script ausführen

Zeit: 2 Min.

Jetzt holen wir das Let’s Encrypt-Cert.

Terminal öffnen.
In den WarpPool-Ordner wechseln — den Pfad durch dein eigenes Clone- Verzeichnis ersetzen:
```
cd /pfad/zu/dvb-WarpPool
```
Script starten:
```
./scripts/setup-tls-public.sh
```
Das Script fragt dich:
```
? DuckDNS Subdomain (ohne .duckdns.org):
```
→ warppool-oliver (oder was du in Phase 1 gewählt hast)
```
? DuckDNS Token (32-Hex aus deinem Account-Settings):
```
→ den Token aus Phase 1 reinpasten
Das Script läuft jetzt durch:
- Installiert acme.sh (Let’s Encrypt CLI) wenn nicht da → ~30s
- Holt das Cert via DNS-01-Challenge:
  - Setzt einen TXT-Record bei DuckDNS
  - Wartet bis DNS propagiert ist (~30-60s)
  - Let’s Encrypt prüft den TXT-Record → bestätigt dass du die Domain kontrollierst
  - Cert wird ausgestellt + lokal gespeichert
- Installiert Cert + Key nach ~/Library/Application Support/dvb-WarpPool/tls/{cert,key}.pem
- Alte self-signed Files werden als .bak-<unix-ts> gesichert
- Registriert sich selbst im Cron für Auto-Renewal nach 60 Tagen

Am Ende siehst du:

✓ TLS-Setup für warppool-oliver.duckdns.org abgeschlossen

Nächste Schritte:
  1) WarpPool-Daemon neustarten ...
  2) Auf der Bitaxe (Pool Configuration): ...
  3) Fritz!Box prüfen: ...
  4) Test (von extern oder im LAN): ...

Phase 5 — Daemon neu starten

Zeit: 30 Sek.

Der Daemon lädt das Cert nur beim Start. Also einmal neustarten:

pkill -f dvb-warppool-daemon
sleep 2
open /Applications/dvb-WarpPool.app

Nach 3-5 Sekunden ist der Daemon wieder da. Prüfen:

tail -20 ~/Library/Application\ Support/dvb-WarpPool/daemon.log | grep -i "tls"

Sollte zeigen:

spawning TLS stratum listener bind=0.0.0.0:3334 cert=/Users/Oliver/Library/Application Support/dvb-WarpPool/tls/cert.pem
stratum-v1 TLS server listening bind=0.0.0.0:3334 max_conn=64

Phase 6 — Verifikation

Zeit: 1 Min.

Wir checken dass das Cert von extern als gültig erscheint.

echo | openssl s_client -connect warppool-oliver.duckdns.org:3334 \
  -servername warppool-oliver.duckdns.org 2>&1 \
  | grep -E "Verify return code|subject=|issuer=|Server certificate"

Gut (was du sehen willst):

subject=CN=warppool-oliver.duckdns.org
issuer=C=US, O=Let's Encrypt, CN=R10
Verify return code: 0 (ok)

Schlecht (irgendwas stimmt nicht):

subject=CN=dvb-WarpPool         ← noch das self-signed Cert
Verify return code: 18 (self-signed certificate)

Falls du das schlechte Resultat siehst:

Hast du den Daemon wirklich neugestartet? pgrep -f dvb-warppool-daemon sollte einen anderen PID zeigen als vor dem Restart.
Zeigt die config.toml auf das neue Cert? grep tls_cert_path ~/Library/Application\ Support/dvb-WarpPool/config.toml

Bei “Verify return code: 0” — fertig, Cert ist gültig und Bitaxe wird’s akzeptieren.

Phase 7 — Eigenen Miner umstellen

Zeit: 2 Min. pro Miner.

Beispiel BitForge Nano (Web-UI auf http://192.168.178.44):

Im Browser zu http://192.168.178.44/ (oder wie auch immer dein Bitaxe im LAN heißt).
Pool Configuration → Main Pool Reiter.

Felder so setzen:

Feld	Wert
Stratum Host	`warppool-oliver.duckdns.org`
Stratum Port	`3334`
Stratum User	(bleibt: `bc1q...DEINE_ADRESSE.BitForgeNano`)
Stratum Password	(bleibt was es war, z.B. `x`)
TLS	Enabled (Bundled CA) ← jetzt korrekt

Save klicken.
Bitaxe meldet “must restart this device after saving” → Restart klicken.
Bitaxe rebootet. Nach ~20 Sek. ist er zurück.
Im Bitaxe-UI sollte unter “Status” wieder eine aktive Pool-Verbindung stehen + Shares ticken.
Im WarpPool-Admin (http://localhost:18334/): Worker-Tabelle sollte den Bitaxe weiter zeigen — mit 🔒-Schloss-Icon neben dem Namen für die TLS-Verbindung. Das “Aktive Miner”-Tile zeigt eine “N TLS”-Subzeile mit der Zahl deiner TLS-Verbindungen.

→ Erfolgreich auf TLS umgestellt.

Wiederholung für alle anderen eigenen Miner (NerdOctaxe, NerdQaxe++, Avalon Q etc.). Pro Miner ~2 Min.

Phase 8 — Freunde einladen

Schick deinen Freunden:

Hey, du kannst auf meinen WarpPool mining:

Pool: warppool-oliver.duckdns.org

Port: 3334

TLS: ja, “Enabled (Bundled CA)” / “Strict TLS”

Username: <DEINE_EIGENE_bech32-Adresse>.<beliebiger Worker-Name>

Du bekommst 100% des Rewards wenn dein Miner den Block findet (Solo-Pool, kein Sharing). Wenn der Pool offline ist, geh auf deinen Fallback.

Wichtig: Jeder Freund nutzt seine eigene Wallet-Adresse. WarpPool ist Solo — der Reward geht direkt auf die Adresse die der Miner als User angibt.

Block-Alarm für die ganze Gruppe

Der Pool kann jedem Freund eine Block-gefunden-Benachrichtigung aufs Handy schicken, in der Sekunde in der es passiert. Der einfachste Weg ist ein gemeinsames ntfy-Topic: du konfigurierst [notifier.ntfy] einmal am Pool, deine Freunde installieren nur die ntfy-App und abonnieren den Topic-Namen — ganz ohne Accounts. Wenn du das nutzt, ergänze die Einladung oben um eine Zeile:

Block-Alarm: installiere die ntfy-App und abonniere das Topic <dein-topic-name>

Eine Telegram-Gruppe oder ein Discord-Channel funktionieren genauso. Die komplette Anleitung (englisch): Sharing notifications with friends.

Sleep-Schutz auf macOS

Sobald deine Freunde von außen connecten, muss der Pool 24/7 erreichbar bleiben. Per Default suspendiert macOS das System nach 3 Stunden Idle-Zeit (pmset sleep 180). Während des Sleep:

Bitcoin Core ist eingefroren — getblocktemplate und submitblock timen aus
Stratum-TCP-Verbindungen brechen ab (Bitaxes loggen Connection reset by peer)
Der Hashrate-Chart zeigt nachts mehrere Drops auf 0 mit kurzen Erholungen wenn der Mac für Power Nap oder Notifications kurz aufwacht

Das wird automatisch verhindert. Seit v1.0.6 wrapped der Mac-Launcher den Daemon-Spawn mit caffeinate -i -w <pid>:

-i = verhindert System-Idle-Sleep (CPU + Netzwerk + Bitcoin Core bleiben wach)
-w PID = caffeinate beendet sich automatisch wenn der Daemon stirbt → keine Zombie-Prozesse, kein manueller Cleanup
Display-Sleep funktioniert weiter — du kannst den Bildschirm dunkel werden lassen, Screensaver läuft, alles normal

Verifikation dass es aktiv ist:

ps -A -o pid,ppid,command | grep "caffeinate -i -w $(pgrep -f dvb-warppool-daemon | head -1)"

Solltest eine Zeile sehen: caffeinate -i -w <daemon-pid>.

Die Admin-Profile-Seite (/admin/profile) zeigt eine grüne Info-Card “✓ macOS Sleep-Modus deaktiviert” wenn der Schutz aktiv ist. Falls die Card fehlt: Launcher konnte caffeinate nicht spawnen (sehr unwahrscheinlich — es ist ein System-Binary das auf jedem macOS vorinstalliert ist).

Was NICHT abgedeckt ist

Expliziter Sleep (Apple-Menü → Ruhezustand, oder MacBook-Deckel schließen). Der User will Sleep, also schläft der Pool auch. Deckel öffnen / Maus bewegen und der Pool ist innerhalb Sekunden zurück (Daemon überlebt kurze Suspensions; bei längeren reconnecten die Bitaxes).
Hard-Shutdown / Stromausfall. Bei Sorgen: USV nutzen.
Force-Quit des Launchers. Wenn du den Launcher direkt killst (Activity Monitor → Force Quit), überlebt der Daemon — aber caffeinate’s Parent ist weg, also könnte caffeinate exiten. Sauberer Restart via pkill -f dvb-warppool-daemon oder die .app neu öffnen.

Stromverbrauch

caffeinate -i ist nur ein Sleep-Prevention-Flag — es pinnt nicht die CPU oder hält die Disk drehend. Dein Mac mini / MacBook idled mit dem gleichen Watt-Wert wie sonst auch wenn der Bildschirm aus ist. Der eigentliche Pool-Workload (Stratum-I/O + gelegentliche Bitcoin-Core-RPC) liegt auf Apple Silicon im einstelligen Watt-Bereich. Keine merklichen Auswirkungen auf die Stromrechnung eines Mac mini.

Sleep-Schutz deaktivieren

Wenn der Mac doch schlafen darf (z.B. dir ist Pool-Uptime nachts egal): caffeinate manuell killen:

pkill caffeinate

Der Daemon läuft weiter bis macOS ihn suspendiert.

Es gibt aktuell keinen Config-Flag zum Deaktivieren des Sleep-Schutzes — es ist das richtige Verhalten für fast jeden Pool-Operator, und das Deaktivieren macht den Pool unzuverlässig. Issue aufmachen falls du einen echten Use-Case für Opt-Out hast.

Wartung

Cert-Renewal

acme.sh macht das automatisch alle 60 Tage (Let’s Encrypt-Certs gelten 90 Tage). Du musst nichts tun außer den Daemon einmal neu starten nachdem das Renewal lief, damit er das neue Cert lädt.

Pragmatischer Trick: Cron-Job der das nach jedem Renewal-Versuch macht:

crontab -e

Folgende Zeile dazu:

0 4 * * * cd $HOME && ~/.acme.sh/acme.sh --cron > /dev/null 2>&1 && pkill -f dvb-warppool-daemon ; sleep 3 ; open /Applications/dvb-WarpPool.app

Läuft jeden Tag um 4 Uhr morgens: prüft Renewal-Status, restartet Daemon falls was passiert ist. Wenn nichts zu renewen war, macht der Restart auch keinen Schaden (Daemon ist nach 5s wieder da, Bitaxes reconnecten automatisch).

Manuell Renewal triggern

Falls du testen willst:

~/.acme.sh/acme.sh --renew --domain warppool-oliver.duckdns.org --force

Das --force ignoriert das 60-Tage-Limit.

IP-Wechsel

Solange du die Fritz!Box hast, läuft alles weiter — sie updated DuckDNS ständig. Nur wenn du den Router wechselst (neuer Anbieter, neue Hardware) musst du die DDNS-Config im neuen Router nochmal einrichten (Phase 2).

Stop / Start des Pools

Nichts Besonderes — wie bisher die .app schließen oder pkill -f dvb-warppool-daemon. Bitaxes der Freunde gehen automatisch auf Fallback, kommen zurück sobald dein Pool wieder läuft.

Wenn was schiefgeht

Bitaxe meldet “TLS connection failed”

Fritz!Box Port-Forward weg? nc -zv warppool-oliver.duckdns.org 3334 von extern → muss “succeeded” sagen.
DuckDNS resolved nicht oder auf falsche IP? dig +short warppool-oliver.duckdns.org @8.8.8.8 → muss deine aktuelle Public-IP zeigen (vergleiche mit curl ifconfig.me).

Cert abgelaufen? (sollte nicht passieren wegen Auto-Renewal, aber zur Sicherheit):

echo | openssl s_client -connect warppool-oliver.duckdns.org:3334 \
  -servername warppool-oliver.duckdns.org 2>&1 \
  | openssl x509 -noout -dates

notAfter=... sollte mindestens 30 Tage in der Zukunft sein.

Bitaxe-Firmware-Cache: manche Bitaxe-Firmware-Versionen cachen ein einmal-gefailtes Cert. Bitaxe physisch vom Strom trennen (10 Sek. warten, wieder anstecken), nicht nur Reset-Button.

Script hat irgendwo abgebrochen

Mehrmals ausführen ist OK — das Script ist idempotent. Wenn z.B. acme.sh schon installiert ist, wird es übersprungen.

Falls du komplett neu anfangen willst:

~/.acme.sh/acme.sh --remove --domain warppool-oliver.duckdns.org
rm -rf ~/.acme.sh/warppool-oliver.duckdns.org/

Dann Script nochmal.

Cert lädt nach Restart nicht neu

Daemon zeigt im Log noch das alte Cert?

lsof -p $(pgrep -f dvb-warppool-daemon) | grep cert.pem

Sollte den Pfad zum neuen Cert zeigen. Wenn nicht: nochmal pkill -KILL -f dvb-warppool-daemon (statt normalem pkill) + die .app neu öffnen.

“Rate Limit Exceeded” von Let’s Encrypt

Du darfst nur 5 Certs pro Woche pro Domain. Wenn du beim Testen mehrfach ausgestellt hast: warten oder die Staging-Variante nutzen:

~/.acme.sh/acme.sh --issue --dns dns_duckdns --domain warppool-oliver.duckdns.org \
  --server https://acme-staging-v02.api.letsencrypt.org/directory

Staging-Certs sind nicht in der Mozilla-CA-Liste — funktionieren nicht für Bitaxe, aber zum Testen ob die Infrastruktur läuft.

Komplett rückgängig (zurück auf self-signed)

Falls du doch nur LAN-Betrieb willst:

~/.acme.sh/acme.sh --remove --domain warppool-oliver.duckdns.org
cd ~/Library/Application\ Support/dvb-WarpPool/tls/
# Backup-Files vom Setup-Script restore:
ls -la *.bak-*
# Den jüngsten cert.pem.bak-XXX und key.pem.bak-XXX zurückkopieren:
cp cert.pem.bak-<JÜNGSTER> cert.pem
cp key.pem.bak-<JÜNGSTER> key.pem
pkill -f dvb-warppool-daemon ; sleep 2 ; open /Applications/dvb-WarpPool.app

Plus: Bitaxe wieder auf Port 3333 ohne TLS stellen (oder TLS “Insecure”-Mode).

Security-Hinweise zu dieser Ausbaustufe

Dieses Setup gibt dir:

Verschlüsselten Stratum-Traffic (TLS 1.3 mit AES-256-GCM)
Verifizierte Server-Identität via Let’s Encrypt → kein Man-in-the-Middle kann sich als dein Pool ausgeben
Freunde mit Tippfehler im Hostname bekommen eine Zertifikats-Warnung → fail-safe statt stillem Minen in einen fremden Pool

Es gibt dir nicht:

DDoS-Schutz (64-Verbindungs-Cap, kein Per-IP-Limit)
Authentifizierung über das bech32-Adressformat hinaus (jeder mit deinem Hostname kann einen Miner auf dich richten und Shares einreichen — auf die eigene Adresse)
IP-Privatsphäre der Worker (sichtbar im Admin-Panel + in den Logs)

Für 5-10 Freunde ist das völlig ok. Leakt dein DuckDNS-Hostname öffentlich und Fremde fangen an, auf deinem Pool zu minen, hilft nur ein Hostname-Wechsel. Für echte Abuse-Resistenz brauchst du Stufe 3 — siehe scaling.md.

Zusammenfassung der Befehle

Für später als Spickzettel:

# Setup (1x) — Pfad an dein Clone anpassen
cd /pfad/zu/dvb-WarpPool && ./scripts/setup-tls-public.sh

# Daemon-Restart (selten nötig — erneuerte Certs zieht der Daemon selbst nach)
pkill -f dvb-warppool-daemon ; sleep 2 ; open /Applications/dvb-WarpPool.app

# Manuelles Renewal triggern
~/.acme.sh/acme.sh --renew --domain warppool-oliver.duckdns.org --force

# Cert-Status prüfen
echo | openssl s_client -connect warppool-oliver.duckdns.org:3334 \
  -servername warppool-oliver.duckdns.org 2>&1 \
  | openssl x509 -noout -dates -subject -issuer

# DNS-Resolution prüfen
dig +short warppool-oliver.duckdns.org @8.8.8.8

# Port-Reachability von extern (vom Handy mit Mobilfunk)
nc -zv warppool-oliver.duckdns.org 3334

Viel Erfolg!

Keyboard shortcuts

dvb-WarpPool