Wie man einen vollständigen Bitcoin-Node auf einem VPS betreibt

Ein vollständiger Node ist der einzige Weg, Bitcoin zu nutzen, ohne jemand anderen fragen zu müssen, was die Wahrheit ist. Jede andere Option — ein Block-Explorer, eine Light-Wallet, die mit einem öffentlichen Server spricht, ein Guthaben auf einer Börse — bedeutet, einem Dritten Ihre Historie anzuvertrauen und dabei gleich Ihre Privatsphäre mit abzugeben. Bitcoin Core selbst ist in etwa zehn Minuten installiert. Was tatsächlich entscheidet, ob Ihr Node etwas taugt, ist die Maschine darunter: wie viel Speicherplatz Sie ihr gegeben haben, ob der Upload gemessen wird und was der Host sehen kann.

Was ein vollständiger Node tut — und was nicht

Ein vollständiger Node lädt jeden Block herunter, prüft jede Signatur und jede Konsensregel selbst und führt eine eigene Kopie der aktuell ausgebbaren Coins. Er ist ein Prüfer. Er ist kein Miner, und für sich genommen auch keine Wallet.

• Er validiert unabhängig — kein Explorer, keine Börse und kein Light-Wallet-Server sagt Ihnen, was gültig ist oder wie hoch Ihr Guthaben ist.
• Er verhindert, dass Sie bei jeder Wallet-Synchronisierung Ihre Adressen an den Server eines Fremden preisgeben — das größte Privatsphäre-Leck, das die meisten Bitcoin-Nutzer haben.
• Er leitet Blöcke und Transaktionen weiter — der Teil, der dem Netzwerk hilft und nicht nur Ihnen.
• Er verdient nichts, stimmt über nichts ab und macht Ihre Coins nicht sicherer, wenn Ihre Keys ohnehin schlecht verwahrt werden.

Archival, Pruned oder Indexed: drei sehr unterschiedliche Speicherbedarfe

Diese eine Entscheidung bestimmt, welchen Plan Sie brauchen — treffen Sie sie also, bevor Sie etwas bestellen. Alle drei Modi verifizieren die Chain auf exakt dieselbe Weise; der Unterschied liegt nur darin, wie viel davon nach der Verifizierung auf der Festplatte bleibt.

• Pruned — Core lädt alles herunter und prüft alles, verwirft dann alte Blockdateien und behält nur die jüngsten. Mit prune=5000 bleiben die Blockdaten bei etwa 5 GB; zusammen mit dem UTXO-Set und dem Betriebssystem landen Sie insgesamt bei etwa 25 GB.
• Archival — jeder Block wird für immer aufbewahrt. Das sind heute bereits über 750 GB an Blockdaten, die um etwa 7 GB pro Monat wachsen, dazu kommt noch das UTXO-Set. Sie brauchen diesen Modus, um historische Blöcke an andere Peers auszuliefern oder später einen Reindex durchzuführen, ohne die Chain erneut herunterzuladen.
• Indexed — Archival plus txindex=1, womit Sie jede Transaktion per ID nachschlagen können und was Block-Explorer sowie manche Server-Software voraussetzen. Das legt noch einmal einige Dutzend Gigabyte drauf und lässt sich nicht mit Pruning kombinieren.

Den richtigen VPS für einen Bitcoin-Node wählen: Festplatte, RAM und ein unmetered Port

Bitcoin Core ist genügsam bei der CPU und anspruchsvoll bei der Festplatte. Zufällige Lese- und Schreibzugriffe auf die UTXO-Datenbank entscheiden, ob eine Synchronisierung schnell oder quälend langsam verläuft — deshalb zählt NVMe hier weit mehr als die Anzahl der Kerne. Jeder Plan der Offshore-VPS-Reihe kommt mit Gen4 NVMe im RAID-10 und unmetered Bandbreite, sodass die eigentliche Wahl die Kapazität ist.

• Pruned-Node: VPS-4 für $7.49/mo — 2 vCPU EPYC, 4 GB DDR5 ECC und 60 GB NVMe, mit komfortablem Spielraum für prune=5000 plus Logs. Der VPS-2 für $3.99 funktioniert ebenfalls bei aggressiverem Pruning.
• Pruned-Node mit schneller Synchronisierung: VPS-8 für $13.99/mo — 4 vCPU und 8 GB erlauben es, Core mehrere Gigabyte dbcache zu geben, der wirksamste Hebel für die Sync-Zeit.
• Archival-Node: Nur der VPS-64 für $89.99/mo bietet mit 800 GB NVMe überhaupt genug Platz für eine Chain ohne Pruning — und bei der heutigen Größe bleibt davon kaum ein Jahr Spielraum.

Rechnen Sie bei einem Archival- oder Indexed-Node ehrlich nach, statt reflexartig den größten VPS zu kaufen: Ein dedizierter Server startet bei $64/mo mit 64 GB Arbeitsspeicher und 2 × 1 TB NVMe — damit ist er zugleich günstiger und deutlich geräumiger als die größte VPS-Stufe. Wenn Sie die Chain über Jahre behalten oder daneben einen Electrum-Server und eine ohne KYC gehostete Seite betreiben wollen, fangen Sie gleich dort an, statt später ein zweites Mal aufzurüsten.

Schritt für Schritt: von der Krypto-Aufladung zum synchronisierten Node

1. 01Konto mit einer Wegwerf-E-Mail-Adresse anlegenEine E-Mail-Adresse und ein Passwort. Kein Name, keine Telefonnummer, kein Ausweis — auf unserer Seite verknüpft nichts den Node mit Ihnen.
2. 02Guthaben in Krypto aufladenLaden Sie ein Prepaid-Guthaben mit Bitcoin, Monero oder einem von 8 Coins auf. Es verfällt nie und wird nie eingefroren.
3. 03VPS bereitstellenWählen Sie einen Plan, eine Region und ein Debian- oder Ubuntu-Image. Root-Zugriff steht im Median nach etwa einer Minute bereit.
4. 04Bitcoin Core installieren und den Download verifizierenLaden Sie das Release vom Bitcoin Core-Projekt herunter und prüfen Sie die Signaturen, bevor Sie es entpacken. Wer diesen Schritt überspringt, läuft am Ende die Binary eines Fremden.
5. 05Als eigenen Benutzer unter systemd betreibenEin dedizierter bitcoin-Benutzer, ein Datenverzeichnis, das ihm gehört, und eine Unit-Datei, damit der Node nach einem Neustart von selbst wiederkommt.
6. 06bitcoin.conf schreiben, starten und das Log beobachtenLegen Sie Prune-Level, dbcache und Netzwerkoptionen fest, starten Sie den Dienst und verfolgen Sie das Log, bis der Verifizierungsfortschritt 1 erreicht.

Die bitcoin.conf-Zeilen, auf die es wirklich ankommt

Core wird mit vernünftigen Standardwerten ausgeliefert, und eine gute Konfiguration umfasst meist sechs oder sieben Zeilen. Diese hier lohnt es sich zu verstehen, statt sie nur aus einem Forenpost zu kopieren.

• dbcache — Speicher für die UTXO-Datenbank, standardmäßig 450 MB. Ihn für die Erstsynchronisierung auf einige Tausend anzuheben ist die günstigste verfügbare Beschleunigung, und Sie können ihn danach wieder senken.
• prune — eine Obergrenze in MB für den Blockspeicher, Minimum 550. Später von Pruned auf Archival zu wechseln bedeutet, die Chain erneut herunterzuladen — entscheiden Sie sich also vor dem ersten Start.
• txindex=1 — baut einen vollständigen Transaktionsindex auf. Setzen Sie es nur, wenn ein Tool, das Sie tatsächlich nutzen, es braucht; nachträgliches Hinzufügen erzwingt einen Reindex.
• listen=1 mit geöffnetem Port 8333 — macht Sie zu einem lauschenden Node, den andere Peers erreichen können. Das ist der Unterschied zwischen der bloßen Nutzung des Netzwerks und einem aktiven Beitrag dazu.
• maxuploadtarget — eine weiche tägliche Obergrenze für ausgehenden Traffic, sinnvoll bei jedem Host, der den Transfer misst.
• blocksonly=1 — stoppt das Weiterleiten einzelner Transaktionen. Das senkt die Bandbreite deutlich, auf Kosten eines nützlichen Mempools und der Propagation.

Initial Block Download: was ihn wirklich langsam macht

Die Erstsynchronisierung ist der einzige wirklich schwergewichtige Teil der Aufgabe. Core spielt die gesamte Chain erneut ab, und obwohl es standardmäßig Skript-Prüfungen unterhalb eines fest hinterlegten, aktuellen Blocks überspringt, baut es das gesamte UTXO-Set trotzdem von Grund auf neu auf — die Arbeit wird also von zufälligen Festplattenzugriffen und Hashing dominiert, nicht von Ihrer Verbindung. Auf Gen4 NVMe mit großzügigem dbcache ist eine vollständige Synchronisierung normalerweise in deutlich weniger als einem Tag fertig; derselbe Vorgang auf einer rotierenden Festplatte kann eine Woche dauern. Geben Sie ihm mehr Arbeitsspeicher statt mehr Kerne, und widerstehen Sie der Versuchung, aus Ungeduld neu zu starten: Der Fortschritt wird periodisch geschrieben, aber ein Neustart mitten im Flush kostet Sie den Cache, für den Sie gerade bezahlt haben.

Den Node über Tor betreiben

Ein lauschender Node kündigt sich bei Peers an. Auf einer Clearnet-Adresse ist diese Ankündigung öffentlich und zeigt direkt auf Ihren Server. Core bietet erstklassige Tor-Unterstützung: Geben Sie ihm einen lokalen Tor-SOCKS-Proxy und Zugriff auf den Control Port von Tor, und es veröffentlicht seinen eigenen Onion-Service und nimmt dort eingehende Verbindungen an. Mit onlynet=onion spricht es überhaupt nicht mehr mit dem Clearnet.

Das ist etwas anderes als ein Tor-Relay zu betreiben, das den Traffic anderer Leute trägt und bewusst öffentlich ist. Hier ist Tor lediglich der Weg, auf dem Ihr eigener Node seine Peers erreicht, und der Kompromiss ist gering: Onion-only-Nodes synchronisieren etwas langsamer und schöpfen aus einem kleineren Peer-Pool — für eine Maschine, die Sie durchlaufen lassen, ist das selten ein Problem.

Bandbreite: die Kosten, die niemand einplant

Ein lauschender Node lädt weit mehr hoch, als er herunterlädt. Jeder Peer, der seine eigene Erstsynchronisierung durchführt, kann Hunderte Gigabyte von Ihnen ziehen, und ein gut vernetzter Archival-Node liefert bereitwillig mehrere Terabyte im Monat, wenn Sie ihn lassen. Bei einem gemessenen Host ist das eine Überschreitungsrechnung — genau das Traffic-Profil, das "unlimited"-Hosting-Pläne bewusst ausschließen. Unmetered Transfer ist hier über die gesamte Reihe Standard, und wenn Sie die Chain aktiv für andere säen wollen, bietet die 10 Gbps Unmetered-Reihe ab $34.99/mo einen dedizierten Port dafür. Wenn Sie lieber klein bleiben, deckeln Sie es bewusst mit maxuploadtarget, statt es dem Zufall zu überlassen.

Wallets, einen Electrum-Server oder BTCPay anbinden

Ein Node allein ist nur die halbe Miete — der Sinn der Sache ist, dass Ihre eigene Software mit ihm spricht statt mit dem eines Fremden. Wallets wie Sparrow und Specter verbinden sich über einen Tunnel direkt mit der RPC von Core. Wallets mit Electrum-Protokoll brauchen einen Server dazwischen: electrs oder Fulcrum bauen ihren eigenen Index aus den rohen Blockdateien auf — einer der konkreten Gründe, auf Pruning zu verzichten. Und wenn Sie selbst Zahlungen annehmen wollen, entfernt BTCPay Server, betrieben gegen Ihren Node, den Zahlungsdienstleister vollständig — dieselbe Self-Hosting-Logik wie beim Aufsetzen einer Website ohne KYC.

Eine Regel gilt unabhängig vom Stack: Der Node verifiziert, und Ihre Keys leben woanders. Nutzen Sie eine Hardware-Wallet oder einen Offline-Signer und lassen Sie die gemietete Maschine ausschließlich validieren. Eine Box, die Ihnen nicht physisch gehört, ist kein Ort für nennenswerte Beträge.

Der ehrliche Privatsphäre-Kompromiss bei einem Node, der Ihnen nicht gehört

Ein Node auf einem VPS ist nicht dasselbe wie einer unter Ihrem Schreibtisch, und es lohnt sich, genau zu benennen, warum. Er beseitigt das größte und häufigste Leck: Anfragen an öffentliche Explorer und Electrum-Server Dritter, die genau protokollieren, nach welchen Adressen Sie gefragt haben. Was er nicht beseitigen kann, ist der Host. Wer physischen Zugriff auf eine Maschine hat, kann im Prinzip ihre Festplatte und ihren Arbeitsspeicher auslesen, und Festplattenverschlüsselung auf einem entfernten Server schützt Sie vor einer gestohlenen Festplatte, nicht vor einer laufenden.

Die nützliche Frage lautet also nicht "kann der Host es sehen", sondern "weiß der Host, wer ich bin". No-KYC-Hosting beantwortet genau das: eine E-Mail-Adresse und ein Passwort, keine Verifizierung, nichts in den Akten, das geleakt oder per Vorladung herausgegeben werden könnte. Die Zahlung aus einem Krypto-Guthaben entfernt die Bank. Wie weit Sie das bei der Zahlung treiben, ist eine Frage des Threat-Modells — Bitcoin ist pseudonym, nicht anonym, sodass Coins, die zu einer verifizierten Börse zurückverfolgt werden, immer noch irgendwohin führen, während das Aufladen in Monero diese Lücke auf Protokollebene schließt. Dieselbe Überlegung gilt für das Betreiben eines Monero-Node, wo es die Verbindung zwischen Wallet und Node ist, die Sie schützen.

Fehler, durch die ein Node hängen bleibt, untätig ist oder offenliegt

• Die Festplatte läuft mitten in der Synchronisierung voll, weil Pruning erst im Nachhinein entschieden wurde — legen Sie es vor dem ersten Start fest, nicht auf halbem Weg.
• Port 8333 bleibt an der Firewall geschlossen, sodass der Node nur ausgehende Verbindungen aufbaut und nie einen einzigen Peer bedient.
• RPC "nur zum Testen" an 0.0.0.0 gebunden — auf einer öffentlichen IP innerhalb von Stunden gefunden.
• txindex reflexartig auf einer kleinen Festplatte aktiviert, dann die Erkenntnis, dass es einen vollständigen Reindex braucht, um es wieder zu entfernen.
• Der Node läuft als root aus einem Home-Verzeichnis ohne systemd-Unit, sodass ein einziger Neustart das Experiment still beendet.

Keiner dieser Fehler ist exotisch. Sie passieren, wenn die Maschine allein nach Preis ausgewählt wird und die Details auf später verschoben werden. Wählen Sie die Festplatte für den Modus, den Sie tatsächlich wollen, halten Sie den Peer-Port offen und die RPC geschlossen, und ein Bitcoin-Node gehört zu den anspruchslosesten Dingen, die Sie jahrelang durchlaufen lassen können.