Bitcoin Full-Node und Electrum Server auf der Synology mit Docker aufsetzen

[synick]

Hallo.

Hier zeige ich Euch, wie Ihr auf Eurer Synology einen Bitcoin Full-Node und einen ElectrumX-Server mit Hilfe von Docker installieren könnt. Auf einer DS224+ läuft er, einmal fertig konfiguriert, erstaunlich wenig ressourcenhungrig.

Disclaimer: Die hier verwendeten Container kommen nicht von mir. Ich lehne jede Verantwortung über den Inhalt oder die Funktionen der Container ab. Alles was Ihr hier macht tut Ihr auf eigenes Risiko! Sollte klar sein.


Fragen vorab:

- Warum ein Bitcoin Full-Node?

Diese Frage habt Ihr Euch sicher schon selbst beantwortet, sonst würdet Ihr Euch nicht die Mühe machen, dieses Tutorial durchzulesen.

- Warum einen ElectrumX – Server?

Sobald Ihr den Full-Node und den ElectrumX Server am Laufen habt, könnt Ihr Euch mit Eurem Electrum-Wallet direkt mit Eurem eigenen Knotenpunkt verbinden. Das geht mit dem Bitcoin-Node allein leider noch nicht.

Vorteil: wenn Ihr eine Transaktion durchführt, dann verlässt Eurer privater Schlüssel nicht das Heimnetz. Euer ElectrumX Server startet die Transaktion mit Eurem privaten Schlüssel und die Verifizierung läuft direkt mit Eurem eigenen Knoten. Auch sonst laufen keine Daten zwischen dem Electrum-Wallet und dem ersten Server mit dem Ihr verbunden seit über das öffentlich Netz. Ihr habt also ein Stück mehr Sicherheit (vorausgesetzt, Ihr vertraut den Docker Containern!)


Was braucht Ihr?

- Eine DS mit mehr als 2GB installiertem RAM und somit der Möglichkeit, Euch den Docker Container Manager installieren zu können. Je mehr RAM, desto immer besser.

- Knapp 1TB Speicherplatz. Da mir mein teurer NAS-Speicher dazu mit Abstand zu schade it, habe ich mir eine externe SSD angehängt. Vorsicht: es sieht so aus, als wären nicht alle externen Laufwerke 100%ig kompatibel. Ich hatte schon Festplatten, die nach der Zeit wieder ausgeworfen wurden. Ich selbst nutze eine Crucial X9 2TB Portable SSD Festplatte, die seit Wochen absolut stabil läuft. Generell würde ich zu mehr als 1TB raten. Es muss die gesamte Blockchain heruntergeladen werden, die jetzt (Stand Ende 2024) etwa 750GB groß ist. Dazu kommen noch ca. 120GB, die der Electrum sich zieht. Da wird es nicht allzu lange dauern, bis 1TB nicht mehr reicht.


Was setze ich voraus?

- Dass Ihr Docker, und darin den Portainer IO installiert habt und Euch ein MacVLAN Netzwerk eingerichtet habt. Wie man das alles macht hat Jürgen in diesem einzigartig tollem Video anhand des Piholes zusammengefasst. Pihole sollte man imho ohnehin haben.


Wenn Ihr das alles habt, kannst losgehen:

- Ladet Euch die Datei Bitcoiin_Stack.zip herunter und entpackt das zip-file.

- Öffnet den Portainer

- Wählt im linken Fenster „Stacks“ aus.

- Oben rechts „+ Add Stack“

- Gebt dem Container einen Namen, z.B. „bitcoind“

- Den dicken button „Web editor“ bitte angewählt lassen.

- Öffnet die heruntergeladene Textdatei biitcoind.txt

-Passt folgende werte in der Datei an, bzw. lest wozu sie da sind:


Im Folgenden begrenzen wir später den Knoten in seinem Tun nach Belieben. Vorerst geben wir ihm aber alle Netzressourcen. Entfernt also vorerst hier die Rauten am Anfang der Zeilen.

Hinweis: Bitte in den Textdateien editieren. Nichts aus den unteren Feldern kopieren, da die Einrückung hier nicht stimmt.

# - "-maxconnections=50" # Maximale Verbindungen auf 50 setzen
# - "-maxuploadtarget=5000" # Upload auf 5000 MB pro Monat beschränken
# - "-blocksonly=1" # Nur Blöcke propagieren, keine Transaktionen
# - "-maxreceivebuffer=50000" # Empfangspuffergröße begrenzen
# - "-maxsendbuffer=50000" # Sendepuffergröße begrenzen

Diese beiden Ports braucht der Knoten. Diese Ports müssen so auch in Eurem Router freigegeben, und unter dieser Adresse durchgeleitet werden.

expose:
- "8332/tcp"
- "8333/tcp"

Hier wählen wir eine IP-Adresse aus unserem MacVLAN Network aus. Wir verwenden das Default Network das wir weiter unten noch definieren.

networks:
default:
ipv4_address: EUREBITCOIN-IP

Wir geben auch den Port 80 frei und legen den internen Bitcoin Pfad auf einen Pfad auf der Synology. Bei mir ist das ein USB-Laufwerk.

ports:
- 80:80
volumes:
- "/volumeUSB1/usbshare/bitcoin:/bitcoin/.bitcoin"

Wer möchte, der kann den Knoten auf z.B. die Kerne 2 und 3 begrenzen. Ebenso kann man den maximalen RAM speicher begrenzen, den sich der Container maximal als Cache nehmen soll. Ich habe 18GB RAM, da bekommt der Knoten 6GB zur Verfügung.

# cpuset: "2,3" # Begrenze den Container auf CPU 2 und 3
deploy:
resources:
limits:
memory: 6g
reservations:
memory: 6g

mem_limit: 6g
memswap_limit: 6g

Netzwerk. Ich habe es genau so angelegt, wie Jürgen es in seinem Video beschrieben hat. Das wird hier als Default gesetzt

networks:
default:
name: mvl
external: true

Jetzt koipert Ihr den ganzen Text und fügt ihn im Stack Editor ein.

Nun öffnet Ihr die heruntergeladene Datei bitcoin.conf und passt

rpcuser=EUERUSER

rpcpassword=EUERPASSWORT

an. Weiter unten dann das Netzwerk das Euer Router Euch zur Verfügung stellt anpassen.

rpcbind=0.0.0.0# alle im Netzwerk dürfen zugreifen
rpcport=8332 # Der Standard-RPC-Port (kann angepasst werden)
#rpcallowip=192.168.178.248 # Erlaubt Verbindungen von der IP-Adresse deines ElectrumX-Servers (oder deinem lokalen Netzwerk)
#pcallowip=0.0.0.0/0 # Erlaubt alle Verbindungen, alle netzwerke
rpcallowip=192.168.178.0/24 # (Zugriff nur für IPs im Netzwerk 192.168.178.*)

Datei speichern und in Euer bitcoin Verzeichnis kopieren. Bei mir wäre das

/volumeUSB1/usbshare/bitcoin

Wenn Ihr damit fertig seid, dann einfach den Button „Deploy the stack“ oder „Update the stack“ im Portainer drücken. Beim ersten Start muss erst noch der Container heruntergeladen werden.

Kleiner Tipp: wenn das nicht funktioniert, dann einfach im Synology Container Mager unter Registrierung nach bitcoind suchen. Der Container den wir verwenden ist

kylemanna/bitcoind

Bei mir ist es gleich der erste Treffer. Den dann herunterladen und den Stack noch einmal starten.

Jetzt gerne mal ins Logfile schauen und ggf. auf Fehler achten.

Was passiert jetzt?

Zunächst versucht der bitcoind sich mit dem Bitcoin Netz zu verbinden. Sobald eine Verbindung aufgebaut ist fängt er an, sich die gesamte Blockchain herunterzuladen. Da kann man schon mal gucken, ob die Daten auch im richtigen Verzeichnis landen.

Bei meiner 100MBit DSL Verbindung hat das knapp 1-2 Tage gedauert.

Im Log sieht das Herunterladen der Blöcke dann so aus:

2024-12-18T13:45:56Z UpdateTip: new best=0000000000000000000216651b5c64d69c02bb73f3a18e8c9dd5ce2dc221784a height=875310 version=0x23388000 log2_work=95.334032 tx=1133413881 date='2024-12-18T13:45:42Z' progress=1.000

date='2024-12-18T13:45:42Z' sagt Euch, welchen Block er gerade heruntergeladen hat. Das macht er der Reihenfolge nach. Er lädt dann so lange herunter, bis er den letzten Block geladen hat und macht damit natürlich auch im Betrieb weiter. Ca. alle 15 min gibt es einen neuen Block.

--------------------

Während der bitcoind sich die Blockchain herunterlädt, kann man schon mal an den ElectrumX server gehen. Das funktioniert im Prinzip genauso wie mit dem bitcoind server. Ihr öffnet die Datei

electrumx.txt

Hier passen wir wieder einige Kleinigkeiten an:

- DAEMON_URL=http://EUERUSER:EUERPASSWORT@eurebitcoind-ip:8332 # Der Bitcoin-Node-URL

Hier brauchen ich einen Trick. Der Port 50001 ist bei mir schon im Gebrauch. Deshalb legen wir den Port 50001 mit dem der Container angesprochen wird auf Port 51001. Im Router legen wir aber den externen Port 50001 auf den internen Port 51001 des ElectrumX. Evtl. könnt Ihr aber direkt mit dem Port 50001 arbeiten. Probiert’s aus.

ports:

- "50002:50002" # SSL-Port für Electrum
- "51001:50001" # Nicht-SSL-Port für Electrum

Dann die eigene IP:

networks:
default:
ipv4_address: IP_DIE_DER_ELECTRUM_SERVER_BEKOMMEN_SOLL

Ich gebe dem ElectrumX Server nur eine CPU. Das könnt Ihr aber auch ändern. Könnte sein, dass er sich schneller die Fehlenden Daten herunterlädt, wenn er auf allen Pötten arbeiten kann:

cpuset: "1" # Begrenze den Container auf CPU 1 (0 bleibt frei)


Alles weitere kennt Ihr schon aus dem Bitcoin Container.

Achtung: diesen Container eben kurz starten, damit sichert Ihr die Einstellungen. Ich würde ihn dann aber gleich wieder stoppen, weil Ihr erst abwarten solltet, bis der Bitcoind sich die Blockchain geholt hat.

Dann startet Ihr den Server. Bei mir hat der Download der ca. 120GB so ungefähr eine Woche gedauert.

Ihr könnt im Log beobachten, wie lange es noch dauert. Die ETA Angabe stimmt dabei aber nicht unbedingt. Eigentlich könnt Ihr diese immer mit 2 oder 3 multiplizieren. So war’s bei mir.

In der Zwischenzeit lässt sich das Electrum Wallet nicht mit dem Server verbinden. Entgegen der Manuals auch nicht über andere Ports. Wenn der Server aber aktualisiert ist, könnt Ihr Euer Electrum Wallet aber unter

Werkzeuge → Netzwerk → Übersicht → Server

eintragen:

EUREELECTRUMX-IP:50002

Oder Ihr habt über DynDNS eine eigene domain. Dann eben unter

EUREDOMAIN:50002

Somit geht Ihr dann aber wieder über das öffentlich Netz. Besser ist es, im Heimnetz zu bleiben, zur Not über VPN.

Wenn die Kügelchen unten links und recht grün aufleuchten, hat alles geklappt.

Nun könnt Ihr noch den Bitcoin Knoten noch nach Belieben limitieren.

Das geht, wie oben schon erwähnt, in der command-section des Bitcoin Stacks. Die hier auskommentierten Werte nutze ich. Die maximale Upload-Rate heißt nicht, dass der Knoten anschließend stoppt. Er fährt dann quasi mit reduzierter Leistung weiter.


Viel Spaß und lasst mich wissen, falls es Fragen oder Probleme gibt...

 

[rabbithole]

Danke für den Denkanstoß. Das Projekt hatte ich auch schon länger vor.

Zu Deiner Konfiguration hätte ich paar Fragen:

• Weshalb dieses MacVLAN? Hat das, außer dem Wunsch nur mit IP-Adressen statt mit Ports zu navigieren noch einen anderen Vorteil? Sicherheits-/Privacy-relevant?
• Was macht dieser Abschnitt Deiner Konfiguration? Ich finde dazu nichts im Github "kylemanna/bitcoind"
  

  cap_drop:    
        - "AUDIT_CONTROL"
        - "BLOCK_SUSPEND"
        - "DAC_READ_SEARCH"
        - "IPC_LOCK"
        - "IPC_OWNER"
        - "LEASE"
        - "LINUX_IMMUTABLE"
        - "MAC_ADMIN"
        - "MAC_OVERRIDE"
        - "NET_ADMIN"
        - "NET_BROADCAST"
        - "SYSLOG"
        - "SYS_ADMIN"
        - "SYS_BOOT"
        - "SYS_MODULE"
        - "SYS_NICE"
        - "SYS_PACCT"
        - "SYS_PTRACE"
        - "SYS_RAWIO"
        - "SYS_RESOURCE"
        - "SYS_TIME"
        - "SYS_TTY_CONFIG"
        - "WAKE_ALARM"

• Gehe ich recht in der Annahme, daß, wenn man das Setup nur im lokalen Netz nutzen möchte, die Portweiterleitung im Router nicht braucht?

 

[synick]

Moin Rabbithole.

Weshalb dieses MacVLAN? Hat das, außer dem Wunsch nur mit IP-Adressen statt mit Ports zu navigieren noch einen anderen Vorteil? Sicherheits-/Privacy-relevant?

Also, das Ganze geht bestimmt auch ohne MacVlan. Ich finde es nur extrem praktisch, wenn Container ihre eigen IP bekommen. Ansonsten kannst Du das auch ohne machen und einfach das Standard-Netzwerk nehmen. Dann verbindest Du Dich anschließend mit der Synolgy über die entsprechenden Ports. Allerdings: Du darfst Ports nicht doppelt belegen. Da musst Du dann aufpassen, dann Du einen Port hast, der ansonsten von der Synology nicht benutzt wird.
Du kannst also auch einen container-internen Port (z.B. 5000) auf einen anderen Port legen.

Was macht dieser Abschnitt Deiner Konfiguration? Ich finde dazu nichts im Github "kylemanna/bitcoind"

Ich habe den Container "konventionel" angelegt und dann mit dem Befehl

sudo docker run --rm -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/red5d/docker-autocompose bitcoind

das Docker Compose file (Stack) generiert. Den Kram haut er dann mit mit raus. Ich lasse ihn drin. Den kan man vermutlich auch komplett löschen.
Das kan man übrigens so mit allen Containern machen, die man installiert hat. Ich finde es einfacher, alles im Compose File einzustellen, zu ändern und zu editieren. Das kann man sich dann z.B. wegspeichern und bei der nächsten Installtion ist das ein schnelles copy / paste und fertig.

 

[phifi]

Hey @synick
Danke erstmal für deine ausführliche Beschreibung. Ich versuche gerade hier mein eigenes Setup zum laufen zu bringen. Da ich eine Doppelbelegung der IP Adressen im Netz nicht verhindern kann (der DHCP auf meinem Router lässt leider nicht viele Einstellungen zu), wollte ich mein Setup ohne macvlan machen.

Allerdings scheitere ich am Deployment des bitcoind Images weil mir nicht klar ist, welches Network und welche IP Adresse ich in der bitcoind.txt eintragen muss.

Könntest du mir hier ein Beispiel bringen wie ich das ohne macvlan/mit ports mache?
Konkret geht es mir um diese Teile der Konfiguration:

networks:
default:
ipv4_address: EUREBITCOIN-IP

networks:
default:
name: mvl
external: true

 

[haydibe]

Was macht dieser Abschnitt Deiner Konfiguration? Ich finde dazu nichts im Github "kylemanna/bitcoind"
cap_drop: - "AUDIT_CONTROL" - "BLOCK_SUSPEND" - "DAC_READ_SEARCH" - "IPC_LOCK" - "IPC_OWNER" - "LEASE" - "LINUX_IMMUTABLE" - "MAC_ADMIN" - "MAC_OVERRIDE" - "NET_ADMIN" - "NET_BROADCAST" - "SYSLOG" - "SYS_ADMIN" - "SYS_BOOT" - "SYS_MODULE" - "SYS_NICE" - "SYS_PACCT" - "SYS_PTRACE" - "SYS_RAWIO" - "SYS_RESOURCE" - "SYS_TIME" - "SYS_TTY_CONFIG" - "WAKE_ALARM"

Die Frage ist zwar schon älter, aber ich beantworte sie trotzdem mal.

Das sind Kernel-Capabilities, die sagen welche Fähigkeit des Kernels genutzt werden darf. Mit [cap_drop] wird definiert, dass der Container diese Capaabilities nicht nutzen darf.
Normalerweise arbeitet man hier mit explizitem Whitelisting, statt wie in dem Beispiel mit Blocklisting. Es ist ein Mittel der Sicherheitshärtung. Das Blocklisting hat den Nachteil, dass man nicht weiß, welche Capabilites tatsächlich erlaubt sind, und sollte es mal neue geben, diese direkt nutzbar wären.

Normalerweise sieht es eher so aus:

cap_drop:
  - ALL
cap_add:
  - CAP_CHOWN
  - CAP_DAC_OVERRIDE
  - CAP_SETUID
  - CAP_SETGID

Die Capabilites im Beispiel erlauben dem Root-User innerhalb des Containers
- den Besitzer von Verzeichnissen ändern zu dürfe, selbst wenn Root nicht auf das Verzeichnis zugreifen dürfte (weil nicht Owner, nicht in der Gruppe, oder Berechtigung für Gruppe Other nicht ausreichend)
- darf Process mit anderer UID und GID starten

Die Whitelist-Variante über cap_drop: [ALL] und cap_add: folgte dem Prinzip der geringsten Überraschung