Full Node verstehen

Ein Full Node ist die vollständige Bitcoin-Software. Er lädt die gesamte Transaktionshistorie seit dem 3. Januar 2009 herunter, prüft jede einzelne Transaktion gegen die Konsensregeln und lehnt alles ab, was nicht passt. Kein Vertrauen, kein Kompromiss.

Die fünf Aufgaben eines Full Nodes

1. Blöcke validieren

Wenn ein neuer Block das Netzwerk erreicht, prüft dein Node:

Ist der Proof of Work gültig? (Hash unter dem Target?)
Stimmt der Previous Block Hash? (Korrekt an den Vorgänger gekettet?)
Sind alle Transaktionen im Block gültig? (Signaturen korrekt? Keine Doppelausgaben?)
Hält der Block die Größenbegrenzung ein? (≤ 4 Mio. Weight Units)
Ist die Coinbase-Belohnung korrekt? (Nicht mehr als erlaubt?)
Stimmt der Merkle Root? (Passt er zu den enthaltenen Transaktionen?)

Wenn auch nur eine Prüfung fehlschlägt, wird der gesamte Block verworfen. Keine Diskussion, keine Ausnahme. Das ist die kompromisslose Natur eines Full Nodes.

2. UTXO-Set pflegen

Das UTXO-Set (Unspent Transaction Output Set) ist die zentrale Datenbank deines Nodes: eine Liste aller noch nicht ausgegebenen Transaktionsausgaben. Stand Anfang 2025 enthält das UTXO-Set etwa 180 Millionen Einträge.

graph LR
    TX1["Transaktion 1"] -->|"erstellt"| U1["UTXO: 0.5 BTC\nan Adresse A"]
    TX1 -->|"erstellt"| U2["UTXO: 0.3 BTC\nan Adresse B"]
    TX2["Transaktion 2"] -->|"verbraucht"| U1
    TX2 -->|"erstellt"| U3["UTXO: 0.49 BTC\nan Adresse C"]

    style U1 stroke:#cc241d,stroke-width:2px,color:#cc241d
    style U2 stroke:#98971a,stroke-width:2px,color:#98971a
    style U3 stroke:#98971a,stroke-width:2px,color:#98971a

UTXO-Set: Erstellt durch neue Transaktionen, verbraucht durch Ausgaben

Wenn jemand Bitcoin ausgeben will, prüft dein Node: Existiert der referenzierte UTXO? Wurde er nicht bereits ausgegeben? Ist die Signatur gültig? Nur wenn alles stimmt, wird die Transaktion akzeptiert — der alte UTXO wird entfernt, neue UTXOs werden angelegt.

Das UTXO-Set ist die Antwort auf die Frage “Wem gehört was?” — und dein Node berechnet es selbst, indem er jede Transaktion seit Block 0 nachvollzieht.

3. Mempool verwalten

Der Mempool (Memory Pool) ist das Wartezimmer deines Nodes: Alle Transaktionen, die zwar gültig sind, aber noch nicht in einem Block gelandet sind. Jeder Node hat seinen eigenen Mempool — es gibt keinen globalen.

Dein Node prüft jede eingehende Transaktion, bevor er sie in den Mempool aufnimmt:

Sind die referenzierten UTXOs vorhanden und unverbraucht?
Ist die Signatur gültig?
Ist die Gebühr hoch genug? (Konfigurierbar via minrelaytxfee)
Überschreitet die Transaktion nicht die Standardregeln? (Größe, Script-Typ)

Transaktionen, die diese Prüfung nicht bestehen, werden nicht weitergeleitet. Dein Node ist also auch ein Torwächter für das Netzwerk.

4. Peers verwalten

Dein Node verbindet sich mit anderen Nodes im Netzwerk — den Peers. Standardmäßig hält Bitcoin Core bis zu 125 Verbindungen: 11 ausgehende (die dein Node aktiv aufbaut) und bis zu 114 eingehende (andere Nodes, die sich bei dir melden).

Über diese Verbindungen tauscht dein Node aus:

Neue Blöcke — sobald ein Miner einen Block findet
Neue Transaktionen — aus dem Mempool
Adresslisten — damit Nodes sich gegenseitig finden

Dein Node bewertet seine Peers: Wer ungültige Daten schickt, wird gebannt. Wer zuverlässig ist, bleibt verbunden.

5. Konsensregeln durchsetzen

Das ist der Kern. Dein Full Node setzt die Regeln durch, die Bitcoin zu Bitcoin machen. Nicht weil jemand es ihm sagt, sondern weil der Code es verlangt:

Regel	Was sie bedeutet
21 Millionen	Es werden niemals mehr als 21.000.000 BTC existieren
Block Weight ≤ 4M WU	Kein Block darf größer sein als 4 Millionen Weight Units
Halvierung	Die Block-Belohnung halbiert sich alle 210.000 Blöcke
Difficulty Adjustment	Alle 2.016 Blöcke wird die Schwierigkeit angepasst
Script-Validierung	Jede Transaktion muss gültige Signaturen enthalten
Timelock-Regeln	Zeitgebundene Transaktionen werden erst nach Ablauf gültig

Ein Full Node akzeptiert keine Abkürzungen. Selbst wenn 99 % der Miner einen ungültigen Block produzieren würden — dein Node würde ihn ablehnen. Das ist der Unterschied zwischen “Konsens” und “Mehrheitsentscheidung”. Bitcoin ist kein Demokratieprojekt — es sind mathematische Regeln.

Der Initial Block Download (IBD)

Wenn du deinen Node zum ersten Mal startest, muss er die gesamte Transaktionshistorie herunterladen und verifizieren — vom Genesis Block (3. Januar 2009) bis heute. Das nennt man Initial Block Download.

Was dabei passiert

Dein Node verbindet sich mit Peers und fragt nach Block Headern
Er lädt die vollständigen Blöcke herunter (ca. 650–700 GB, Stand Anfang 2025)
Jede einzelne Transaktion in jedem Block wird verifiziert — über 1 Milliarde Transaktionen
Das UTXO-Set wird Stück für Stück aufgebaut
Erst wenn alles geprüft ist, gilt der Node als “synchronisiert”

Wie lange dauert das?

Hardware	Dauer (ungefähr)
Raspberry Pi 4 (SSD)	3–7 Tage
Alter Laptop (SSD)	1–3 Tage
Moderner Desktop (NVMe)	6–12 Stunden

Der Flaschenhals ist meistens nicht die Internetverbindung, sondern die CPU (Signaturverifizierung) und die Festplattengeschwindigkeit (UTXO-Set-Updates). Eine SSD ist Pflicht — mit einer HDD dauert der IBD Wochen.

Wenn du den IBD startest, beobachte den Fortschritt mit bitcoin-cli getblockchaininfo. Das Feld verificationprogress zeigt dir, wie weit du bist (1.0 = fertig). Beachte: Die letzten Prozent gehen deutlich schneller als die ersten, weil ältere Blöcke kleiner waren.

Pruned Node vs. Archival Node

Nicht jeder hat 700 GB Speicherplatz übrig. Deshalb gibt es den Pruned Mode: Dein Node lädt und verifiziert trotzdem jeden Block, aber er löscht die rohen Blockdaten danach wieder. Was bleibt, ist das UTXO-Set und genug Blöcke, um funktionsfähig zu bleiben.

Eigenschaft	Archival Node	Pruned Node
Speicherbedarf	~700 GB (wachsend)	5–10 GB (konfigurierbar)
Validierung	Vollständig	Vollständig
Alte Blöcke bereitstellen	Ja	Nein
UTXO-Set	Vollständig	Vollständig
IBD durchgeführt	Ja	Ja
Hilft neuen Nodes beim IBD	Ja	Eingeschränkt

Ein Pruned Node ist genauso sicher wie ein Archival Node. Er hat jede Transaktion geprüft — er speichert nur nicht die Rohdaten. Der einzige Nachteil: Er kann anderen Nodes keine alten Blöcke bereitstellen. Wenn Speicherplatz knapp ist, ist Pruning die richtige Wahl.

Hardware-Anforderungen

Die gute Nachricht: Du brauchst keinen Server. Bitcoin Core läuft auf bescheidener Hardware:

Minimum:

CPU: Dual-Core (ARM oder x86)
RAM: 2 GB (4 GB empfohlen)
Speicher: 10 GB (Pruned) oder 700+ GB (Archival), SSD Pflicht
Internet: 10+ Mbit/s, keine strenge Datenbegrenzung (IBD: ~700 GB Download)

Empfohlenes Setup für zuhause:

Raspberry Pi 4/5 mit 4–8 GB RAM
1 TB externe SSD (USB 3.0)
Ethernet-Verbindung (stabiler als WLAN)
Dauerbetrieb (24/7), Stromverbrauch: ~5–10 Watt

Alternativ tut es auch ein alter Laptop mit SSD oder ein Mini-PC (z. B. Intel NUC). Hauptsache: SSD, nicht HDD.

Laufende Kosten

Posten	Kosten
Strom (5–10 W, 24/7)	~1–2 € pro Monat
Internet (Traffic)	~10–20 GB pro Monat nach IBD
Hardware (einmalig)	50–200 € (je nach Setup)

Für die Kosten eines Streaming-Abos pro Monat betreibst du deine eigene finanzielle Infrastruktur. Kein schlechter Deal.

Was dein Node nicht tut

Ein Full Node ist kein Mining-Rig. Er erzeugt keine Blöcke und verdient kein Geld. Er prüft die Arbeit der Miner. Das ist ein fundamentaler Unterschied: Miner schlagen vor, Nodes entscheiden.

Ein Full Node ist auch kein Wallet. Er speichert und verwaltet keine Schlüssel (es sei denn, du aktivierst die eingebaute Wallet-Funktion). Die Aufgabe des Nodes ist Verifizierung, nicht Verwahrung.

Weiterführend

Bitcoin Core einrichten — Schritt-für-Schritt-Anleitung für deinen ersten Node
Warum eine eigene Node? — Die Argumente für Souveränität
Blöcke und die Timechain — Was genau dein Node beim Validieren prüft
Das UTXO-Modell — Wie Bitcoin Besitzverhältnisse abbildet