Crypto · kein KYC
Bitcoin Core (bitcoind) hosten auf einem Offshore-VPS
Einen eigenen Bitcoin Core Full Node zu betreiben ist die einzige Möglichkeit, die Chain selbst zu verifizieren, anstatt dem Server eines anderen zu vertrauen – und ein Offshore-VPS ohne KYC ermöglicht Ihnen das, ohne Ihre Identität damit zu verknüpfen.
Was es ist
Bitcoin Core (bitcoind) ist die Referenzimplementierung des Bitcoin-Protokolls: Es lädt jeden Block und jede Transaktion herunter, validiert sie unabhängig, leitet sie an Peers weiter und stellt eine JSON-RPC-Schnittstelle bereit, der Ihre Wallet oder Ihre Apps vertrauen können. Ein Full Node bietet Ihnen Validierung auf Self-Custody-Niveau, Privatsphäre gegenüber öffentlichen Block-Explorern und ein Backend für Wallets, Lightning-Nodes, Electrum-Server (Fulcrum/electrs) oder BTCPay Server.
Warum offshore hosten
Die IP-Adresse Ihres Nodes ist für jeden Peer sichtbar, mit dem er sich verbindet. Wird er daher auf einem mit Krypto bezahlten VPS ohne Identitätsprüfung betrieben, bleibt er von Ihrer Heimverbindung und Ihrem Namen entkoppelt. ChainVPS arbeitet ohne KYC und mit unbegrenztem Datenvolumen – wichtig, denn der initiale Block-Download und die laufende Weiterleitung an Peers bewegen Hunderte Gigabyte, die ein gedrosseltes Kontingent sprengen würden.
Das Deployment
Ein funktionierendes Referenz-Setup
Kopieren Sie dies auf eine neue ChainVPS-Instanz. Ersetzen Sie die Platzhalter und starten Sie sie anschließend.
# docker-compose.yml — Bitcoin Core Full Node (standardmäßig pruned für einen kleinen VPS)
# 1) Zuerst eine RPC-Anmeldeinformation generieren (KEIN Klartext-Passwort speichern):
# curl -sSL https://raw.githubusercontent.com/bitcoin/bitcoin/master/share/rpcauth/rpcauth.py \
# | python3 - bitcoin
# Das Skript gibt eine rpcauth=...-Zeile und ein passendes Passwort aus. Die rpcauth-Zeile unten einfügen.
# 2) docker compose up -d dann den IBD verfolgen: docker compose logs -f
services:
bitcoind:
image: bitcoin/bitcoin:28.1
container_name: bitcoind
restart: unless-stopped
stop_grace_period: 2m
user: "1000:1000"
ports:
- "8333:8333" # P2P — öffentlich, ermöglicht das Bedienen/Annehmen von Peers
- "127.0.0.1:8332:8332" # RPC — NUR an localhost gebunden, niemals exponieren
volumes:
- ./bitcoin-data:/home/bitcoin/.bitcoin
command:
- -printtoconsole
- -server=1
- -listen=1
- -prune=10000 # ~10 GB Blöcke; für einen vollständigen archivarischen Node -prune=0 -txindex=1 setzen
- -dbcache=1024 # MB; auf größeren Servern auf 2048-4096 erhöhen, um den IBD zu beschleunigen
- -maxmempool=300
- -maxconnections=40
- -rpcbind=0.0.0.0 # bindet innerhalb des Containers; das Host-Mapping hält es auf 127.0.0.1
- -rpcallowip=172.16.0.0/12 # Docker-Bridge-Bereich, damit host-seitige Tools auf RPC zugreifen können
- -rpcauth=bitcoin:REPLACE_WITH_GENERATED_HASH # <-- hier die rpcauth-Ausgabe einfügen
- -disablewallet=1 # nur Node; diese Zeile entfernen, wenn Sie die eingebaute Wallet nutzen möchten
# Beim ersten Start muss ./bitcoin-data dem uid 1000 gehören: mkdir -p bitcoin-data && sudo chown 1000:1000 bitcoin-dataFirewall
Zu öffnende Ports
| Port | Protokoll | Zweck |
|---|---|---|
| 8333 | TCP | Bitcoin P2P — Peers annehmen und bedienen; der einzige Port, der öffentlich erreichbar sein sollte |
| 8332 | TCP | JSON-RPC-Steuerschnittstelle — nur an 127.0.0.1 binden, Zugriff über SSH-Tunnel oder ein privates Netzwerk |
| 28332/28333 | TCP | Optionale ZMQ-Block-/Tx-Benachrichtigungen für einen Lightning-Node oder Electrum-Server; nur localhost |
| 9050 | TCP | Optionaler lokaler Tor-SOCKS-Proxy, falls Sie bitcoind über Tor betreiben, um Privatsphäre auf Peer-Ebene zu erreichen |
Richtige Dimensionierung
Welchen Plan Sie brauchen
VPS Small (2 vCPU / 4 GB RAM / 60-80 GB NVMe)
prune=10000 behält ~10 GB an Blöcken plus den ~10 GB großen Chainstate; validiert die gesamte Chain und eignet sich ideal als Wallet-/Lightning-Backend, wenn Sie keine historischen Blockdaten benötigen.
VPS Pro oder Storage VPS (4 vCPU / 8 GB RAM / 1 TB Festplatte)
prune=0 speichert jeden Block (~650 GB und weiter wachsend im Jahr 2026); Storage-Pläne bieten günstigen Spielraum bei großen Festplatten, unbegrenztes Datenvolumen deckt den gesamten IBD und die Peer-Weiterleitung ab.
Dedicated oder großer Storage VPS (8+ vCPU / 16-32 GB RAM / 1.5-2 TB NVMe)
txindex=1 zusammen mit Fulcrum/electrs fügt einen großen Adressindex hinzu und bedient viele Wallet-Clients; erfordert schnelles NVMe und RAM für den dbcache und den Neuaufbau des Index.
Beste Standorte: Jeder der 15 Standorte funktioniert, da die Bandbreite von ChainVPS unbegrenzt ist – genau das, was der mehrere hundert GB umfassende IBD und die kontinuierliche Weiterleitung eines Nodes tatsächlich benötigen. Für einen Betrieb ohne Identitätsbindung wählen Sie die Privacy-Standorte — Island, Schweiz, Moldau, Niederlande, Rumänien oder Luxemburg —, wo der Node keine Verbindung zu Ihrem Namen hat; Jurisdiktionen wie Island und die Schweiz sind ebenfalls eine gute Wahl, wenn Sie ihn über Tor betreiben möchten und ein stabiles, privatsphärenfreundliches Zuhause für einen langlebigen Node suchen.
Sichern Sie es ab
Hardening-Checkliste
- Port 8332 niemals dem Internet aussetzen. Das RPC-Mapping wie gezeigt auf 127.0.0.1 belassen und über `ssh -L 8332:127.0.0.1:8332 user@server` erreichen; ein erreichbares RPC mit schwachen oder erratbaren Zugangsdaten ist der klassische Weg, wie Nodes leergeräumt oder gekapert werden.
- Verwenden Sie -rpcauth (ein gesalzener Hash) anstelle von -rpcuser/-rpcpassword, damit kein Klartext-Passwort in der Compose-Datei oder Prozessliste steht; rotieren Sie es, falls der Server jemals geteilt oder als Snapshot gesichert wird.
- Für Privatsphäre auf Peer-Ebene über Tor betreiben: Installieren Sie tor auf dem Host und fügen Sie -proxy=127.0.0.1:9050 -listen=1 -bind=127.0.0.1 sowie einen Onion-Service hinzu, sodass Peers eine .onion-Adresse statt Ihrer VPS-IP sehen. Kombinieren Sie dies mit -onlynet=onion, wenn Sie überhaupt keine Clearnet-Peers möchten.
- Sichern Sie die Firewall mit ufw ab: Erlauben Sie eingehend nur 22 (SSH, idealerweise nur mit Key + verschobenem Port) und 8333, alles andere blockieren. bitcoind öffnet ohnehin seine eigenen ausgehenden Peer-Verbindungen.
- Behalten Sie die Festplatte im Auge. Ein pruned Node bleibt stabil bei ~20 GB, ein ungeprunter Node wächst dagegen kontinuierlich — richten Sie eine Warnung bei Speicherplatznutzung ein und lassen Sie genug Puffer, denn eine volle Festplatte stoppt die Validierung und kann den Chainstate bei einem harten Absturz beschädigen.
- Setzen Sie stop_grace_period (oben 2m) und verwenden Sie `docker compose stop`, niemals einen harten Kill — bitcoind braucht Zeit, um seinen LevelDB-Chainstate sauber zu leeren, sonst riskieren Sie beim nächsten Start einen langsamen Reindex.
Bereitstellen auf
Das richtige ChainVPS-Produkt
Fragen
Hosting Bitcoin Core (bitcoind) — FAQ
Wie viel Speicherplatz brauche ich wirklich?
Ein pruned Node (prune=10000 in der Konfiguration) bleibt bei etwa 15-20 GB und validiert dennoch die gesamte Chain. Ein vollständiger Archivknoten speichert jeden Block, was 2026 bei rund 650 GB liegt und jährlich um etwa 50-70 GB wächst – planen Sie also mit 1 TB oder mehr. Mit txindex=1 oder einem Electrum-Server nähern Sie sich 1.5-2 TB schnellem NVMe.
Wie lange dauert der initiale Block-Download (IBD)?
Auf einem modernen VPS mit unbegrenztem Datenvolumen und dbcache=2048+ dauert die vollständige Synchronisation und Validierung ab Genesis je nach CPU- und Festplattengeschwindigkeit einige Stunden bis etwa einen Tag. Ein höheres -dbcache während der initialen Synchronisation bringt mit Abstand den größten Geschwindigkeitsgewinn. Das ist ein einmaliger Aufwand; danach lädt der Node nur noch neue Blöcke herunter.
Kann ich damit einen Lightning-Node oder Electrum-Server betreiben?
Ja. Aktivieren Sie ZMQ (fügen Sie -zmqpubrawblock und -zmqpubrawtx auf den Ports 28332/28333 hinzu) und richten Sie LND, Core Lightning, Fulcrum oder electrs über das lokale Docker-Netzwerk auf die RPC- und ZMQ-Endpunkte aus. Beachten Sie, dass Fulcrum/electrs txindex=1 benötigen und daher nicht mit einem pruned Node kombiniert werden können.
Ist ein pruned Node weniger sicher oder weniger privat?
Nein. Ein pruned Node führt exakt dieselbe vollständige Validierung jedes Blocks und jeder Transaktion durch wie ein Archivknoten — er verwirft lediglich alte Blockdaten, nachdem sie geprüft wurden. Sicherheit und Privatsphäre Ihrer Wallet sind identisch. Sie verlieren lediglich die Fähigkeit, historische Blöcke an andere Peers auszuliefern oder beliebige alte Transaktionen erneut zu scannen.
Ist die IP-Adresse meines Nodes sichtbar?
Ja — jeder Peer, mit dem Sie sich verbinden, sieht standardmäßig die IP-Adresse Ihres Nodes. Genau deshalb hilft der Betrieb auf einem Offshore-VPS ohne KYC: Die IP gehört zu einem Server ohne Verbindung zu Ihrer Identität oder Heimverbindung. Für vollständige Privatsphäre auf Peer-Ebene betreiben Sie bitcoind über Tor wie in den Hardening-Tipps beschrieben, sodass Peers nur eine .onion-Adresse sehen.
Mehr zum Selbst-Hosten
Weitere One-Click-Stacks
Bereitstellen Bitcoin Core (bitcoind)
in den nächsten 60 Sekunden.
Unlimitierte Bandbreite · DDoS inklusive · 21 Kryptowährungen · Kein KYC.