Was ist Pruning und welche Vor- und Nachteile gibt es
Der Begriff Pruning stammt aus dem Englischen und bedeutet so viel wie „beschneiden“ oder „ausdünnen“. Im Kontext von Bitcoin bezeichnet Pruning das gezielte Löschen alter Blockchain-Daten, um Speicherplatz zu sparen – ohne dabei die Sicherheit der Node oder des Netzwerks zu gefährden.
Eine pruned Node ist also eine Bitcoin-Fullnode, die nicht die gesamte Blockchain speichert, sondern nur die aktuellen und relevanten Daten, die sie für die Validierung neuer Blöcke und Transaktionen benötigt.
Wie funktioniert Pruning technisch?
- Sobald eine Node vollständig synchronisiert ist (also alle Blöcke heruntergeladen und geprüft hat), kann sie alte Blöcke löschen.
- Dies geschieht durch die Einstellung:
prune=
#setzt man hier z.B. prune=100000, werden nur die letzten 100GB an Blockdaten gespeichert.- im
bitcoin.conf. Die Zahl gibt die Größe des Speichers in MB an, den die Node maximal für Blöcke verwenden darf. - Bitcoin Core löscht dann automatisch die ältesten Blöcke, nachdem sie vollständig verarbeitet wurden.
- UTXO-Daten (unspent transaction outputs) bleiben erhalten – das ist entscheidend, denn sie sind nötig, um neue Transaktionen zu validieren.
Wichtig: Nur Blöcke können gepruned werden. Der UTXO-Set, also die Menge aller noch nicht ausgegebenen Coins, muss immer vollständig vorhanden sein.
Ein Stratum Server für das Bitcoin Mining kommt hiermit nur 550MB an Blöcken aus, mehr braucht er nicht, da er Blocktemplates immer nur anhand des neusten Blockes zur Verfügung stellt, mehr nicht.
Vorteile von Pruning
| Vorteil | Erklärung |
|---|---|
| 💾 Weniger Speicherverbrauch | Anstatt >500 GB Blockchain zu speichern, reichen z. B. 2–5 GB. |
| 🧩 Volle Validierung | Auch pruned Nodes validieren alle Blöcke vollständig – also kein Light Client! |
| 🚀 Ideal für kleine Server & Raspi-Projekte | Pruning macht Bitcoin-Nodes auch auf Geräten mit kleiner SSD praktikabel. |
| 🔒 Datenschutz | Man betreibt seine eigene Node und muss sich nicht auf Drittanbieter verlassen. |
Nachteile von Pruning
| Nachteil | Erklärung |
|---|---|
| 📉 Kein Zugriff auf alte Transaktionen | Man kann z. B. keine vollständige Wallet-Historie oder Explorerdienste bereitstellen. |
| ❌ Nicht mit Indexern kompatibel | Dienste wie ElectrumX, Electrs, Fulcrum oder Blockexplorer erfordern Zugriff auf alle Blöcke. |
| 🔄 Kein Rescan alter Adressen möglich | Wenn man eine alte Wallet importiert, fehlen die Blöcke für den Scan. |
| ⚠️ Kein Service für Dritte | Möchte man z. B. anderen Wallets über Electrum Schnittstellen bereitstellen, reicht eine pruned Node nicht. |
Für wen ist Pruning sinnvoll?
Pruning eignet sich perfekt für:
- Privatnutzer, die ihre eigene Node betreiben möchten
- Raspberry Pi-Setups mit begrenztem Speicher z.B einer alten 1TB Platte.
- Wallet-Validierung zu Hause, um nicht auf Dritte angewiesen zu sein
- Netzwerk-Teilnehmer, die zur Dezentralisierung beitragen wollen, ohne hunderte GB speichern zu müssen
- Pool Betreiber: benötigen nicht die komplette Chain um Templates zur Verfügung zu stellen
Nicht geeignet ist es für:
- Blockexplorer
- öffentliche Electrum-Server
- Lightning-Setups, die Wallet-Rescans benötigen
- Developer, die tief in die Blockchain schauen müssen
Pruning Möglichkeiten nach vollständiger Synchronisation
Node synchronisiert, ohne Pruning
Bitcoin Core erlaubt es, den prune-Wert (z.B. prune=100000, was ~100 GB entspricht) auch nach einem vollständigen Blockchain-Sync zu setzen, ohne dass ein Reindex durchgeführt werden muss. Beim nächsten Start mit aktiviertem Pruning beginnt der Node automatisch damit, alte Blöcke zu löschen, bis der Speicherverbrauch unter dem angegebenen Zielwert liegt (bitcoin.stackexchange.com). Es ist also keine erneute Synchronisation der gesamten Blockchain nötig – im Gegenteil, durch das Pruning wird Festplattenplatz freigegeben. (Nur wenn man später von einem geprunten Node zurück zu einem ungeprunten wechseln möchte, wäre ein erneutes Herunterladen/Reindexieren der Blockchain erforderlich (bitcoincore.org.)
Beispielsweise beträgt der minimale zulässige Prune-Wert 550 MB, was sicherstellt, dass mindestens die letzten 288 Blöcke (ca. 2 Tage) aufbewahrt werden (bitcoincore.org). Dieser Mindestwert wurde gewählt, um kurzfristige Reorganisationen oder Wallet-Rescans zu ermöglichen. Höhere Werte wie prune=100000 bedeuten entsprechend mehr aufbewahrte Blöcke (100 GB entspricht grob den letzten ~1–2 Jahren an Blöcken, je nach Blockgröße). Die Umstellung von einem vollständigen Node auf einen geprunten Node erfolgt nahtlos: Bitcoin Core erkennt die vorhandenen Blockdaten und entfernt ältere Blöcke, bis das Speicherlimit erreicht ist. Ein Reindex oder Neu-Download ist dafür nicht erforderlich (bitcoin.stackexchange.com). Es empfiehlt sich allerdings, vor dem Pruning ein Backup der Wallet anzulegen und sicherzustellen, dass kein Wallet-Rescan nötig ist, der in pruned Mode mangels alter Blöcke fehlschlagen würde (siehe nächste Sektion zur Wallet-/Lightning-Problematik).
Node synchronisert jedoch mit aktiviertem Pruning
Sobald Ihr in Eurer bitcoin.conf z. B. prune=10000 gesetzt habt, betreibt Bitcoin Core Eure Node im sogenannten Pruned Mode. Das bedeutet:
- Alte Blöcke werden dauerhaft gelöscht, sobald sie nicht mehr zum Validieren benötigt werden.
- Das betrifft nicht nur die Blöcke selbst, sondern teilweise auch Metadaten, die zur Verwaltung der Chain notwendig sind.
Wenn Ihr nun nach einiger Zeit entscheidet, dass Ihr doch alle Blöcke behalten möchtet – z. B. für einen Blockexplorer, Electrum-Server oder zur Archivierung –, reicht es nicht, einfach den prune-Eintrag zu entfernen oder auf prune=0 zu setzen.
Warum ein einfacher Wechsel nicht funktioniert
Eine geprunte Node hat nur einen Teil der Blockchain auf der Festplatte – z. B. nur die letzten 10 GB (≈1 Jahr Blockchain-Historie). Wenn Ihr jetzt prune=0 in die bitcoin.conf schreibt:
- Bitcoin Core erkennt, dass viele Blöcke fehlen.
- Da ein vollständiger Node aber die komplette Blockchain seit Genesis-Block (2009) benötigt, ist das System nicht mehr vollständig.
- Deshalb bricht Bitcoin Core mit einem Fehler ab und fordert Euch auf, die Blockchain neu zu synchronisieren.
Die einzige Möglichkeit, wieder eine vollständige Node zu betreiben, ist:
bitcoind -reindex
Oder Ihr löscht das komplette .bitcoin/blocks und .bitcoin/chainstate Verzeichnis (bzw. Euer entsprechendes datadir) und startet den Sync komplett neu – diesmal ohne prune=….
Prune-Größe und Lightning: Mindestanforderungen
Für den Betrieb von Lightning-Nodes (LND oder Core Lightning) auf einem geprunten Bitcoin-Core-Backend gelten besondere Anforderungen an die Blockverfügbarkeit. Zwar können beide Lightning-Implementierungen grundsätzlich mit einem geprunten Full Node funktionieren (bitcoin.stackexchange.com), jedoch dürfen keine für Lightning relevanten Blöcke gelöscht werden, da sonst die Lightning-Software wichtige on-chain Ereignisse nicht nachverfolgen kann. In der Praxis bedeutet das:
- Alle Blöcke seit Erzeugen der Lightning-Wallet bzw. seit der ältesten aktiven Channel-Eröffnung müssen verfügbar bleiben (dev.lightning.community). Die offizielle LND-Dokumentation betont, dass bei Verwendung eines geprunten Nodes sichergestellt sein muss, dass LND alle Blöcke seit dem „Geburtszeitpunkt“ der Wallet und seit dem Alter des ältesten Channels auf der Festplatte hat (dev.lightning.community). Andernfalls könnte LND Transaktionen (z.B. eine alte Funding- oder Closing-Transaktion) nicht mehr nachträglich finden, falls ein Rescan nötig wird.
- Ein Lightning-Node darf nicht zu weit hinter der Blockchain zurückfallen, da ein geprunter Bitcoin-Core alte Blöcke nicht mehr liefern kann. Die Core-Lightning-Dokumentation warnt ausdrücklich: Wenn
bitcoindeinen Block bereits geprunt hat, den Core Lightning noch nicht verarbeitet hat (etwa weil der Lightning-Daemon länger offline war), kann Core Lightning sich nicht mehr synchronisieren und bleibt stecken (docs.corelightning.org). Ähnliches gilt für LND – es ist möglich, dass LND beim Aufholen der Blockchain eine benötigte bestätigte Transaktion (z.B. eine Channel-Schließung) nicht mehr über RPC abrufen kann, wenn der betreffende Block inzwischen gelöscht wurde. In solchen Fällen kann LND aus dem Sync fallen (zeigt z.B.synced_to_chain = false) und benötigt einen manuellen Eingriff oder Neustart (github.com).
Angesichts dieser Anforderungen ist die minimal mögliche Prune-Größe von 550 MB (≈288 Blöcke) für zuverlässigen Lightning-Betrieb meist nicht ausreichend. 288 Blöcke entsprechen nur zwei Tagen: Würde der Lightning-Node z.B. eine Woche offline sein, wären die fehlenden ~1008 Blöcke bereits nicht mehr alle auf der Disk vorhanden, was zu Synchronisationsproblemen führt. Zudem bleiben Lightning-Channels oft deutlich länger als zwei Tage offen – die Blöcke der Channel-Eröffnungen würden bei aggressivem Pruning irgendwann entfernt. Ein Lightning-Node prüft jedoch beim Start typischerweise den Status seiner Funding-Transaktionen (und gegebenenfalls deren Bestätigungen) in der Blockchain. Wenn diese ursprünglichen Funding-Blöcke geprunt sind, kann es zu Fehlern oder hängenden Channels kommen (ein früher c-lightning-Bug zeigte z.B., dass bei prune=550 Lightning beim Start ~96 Blöcke hinterherhinkte, da ein benötigter Block “Block not available (pruned data)” wargithub.com).
Praktisch bewährte Empfehlung: Verwende einen deutlich höheren Prune-Wert, um einen ausreichenden Puffer an Blöcken vorzuhalten. Häufig genannte Werte sind mindestens 5–10 GB statt nur 550 MB. Beispielsweise empfiehlt ein Entwickler des Node Launcher (LND-Launcher) mindestens prune=10000 (≈10 GB) oder mehr freien Speicher, damit das Pruning nicht zu aggressiv ausfällt (github.com). Auch Anwenderberichte zeigen, dass stärkeres Pruning die Stabilität von LND beeinträchtigen kann („je aggressiver man prunet, desto häufiger verliert LND die Synchronisation mit der Chain“(github.com). Mit ~10 GB Pruning-Limit bleiben grob die letzten 1–2 Monate an Blöcken erhalten, was kurze Offline-Zeiten problemlos überbrückt. Wer sicherstellen will, dass auch sehr alte Channels (z.B. seit 2018) abgedeckt sind, müsste entsprechend einen viel größeren Wert oder gar kein Pruning einstellen – einige Routing-Node-Betreiber verzichten daher auf aggressives Pruning zugunsten der Zuverlässigkeit (docs.lightning.engineering). Zusammengefasst sollte die Prune-Größe so gewählt werden, dass die ältesten relevanten Blöcke für Ihre Lightning-Channels nicht gelöscht werden.
Unterschiede zwischen LND und Core Lightning
Beide Lightning-Implementierungen haben grundsätzlich dieselbe Herausforderung: Sie benötigen Zugriff auf bestimmte Blockchain-Daten (Blocks/Transactions), um Channel-Funding und -Closing sowie on-chain HTLC-Timeouts etc. überwachen zu können. Allerdings gibt es leichte Unterschiede in der offiziellen Haltung und Handhabung:
- LND (Lightning Labs) – LND unterstützt seit Bitcoin Core 0.16+ zwar den Betrieb mit einem geprunten Backend, steht dem aber noch etwas vorsichtig gegenüber. In der Doku heißt es klipp und klar, dass pruned Nodes nicht vollständig unterstützt werden und der Nutzer selbst sicherstellen muss, dass alle benötigten Blöcke vorhanden sind (dev.lightning.community). LND benötigt keinen
txindex(es kann fehlende Transaktionen notfalls über das P2P-Netz laden), aber wenn ein benötigter Block fehlt, gerät LND ins Hintertreffen. In der Praxis zeigt sich, dass LND bei sehr knappem Pruning gelegentlich den Sync verliert und manuell neu gestartet werden muss (github.com). Die Entwickler arbeiten zwar an Verbesserungen (z.B. Unterstützung von BIP157/158 Blockfiltern und manueller Prune-Steuerung(github.comgithub.com), dennoch sollte man LND mit Vorsicht prunen. - Core Lightning (ehem. c-lightning, Blockstream) – Core Lightning wird von Haus aus häufig mit geprunten Nodes betrieben und gilt als prune-freundlich. Offiziell heißt es, Core Lightning benötige lediglich einen vollständig synchronisierten
bitcoindund verwendet JSON-RPC (keintxindexnötig) (docs.corelightning.orgdocs.corelightning.org). Allerdings warnt auch CLN: Wenn der Bitcoin-Core einen Block schon gelöscht hat, bevor Core Lightning ihn verarbeiten konnte (etwa wegen längerer Downtime von CLN), kann CLN nicht mehr aufholenn (docs.corelightning.org). Daher empfiehlt man, die Differenz zwischen der von CLN verarbeiteten Blockhöhe und der aktuellenbitcoind-Höhe im Auge zu behalten und notfalls einzugreifen, bevor die Lücke zu groß wird (docs.corelightning.org). Insgesamt wird Core Lightning als etwas robuster gegenüber Pruning gesehen, weil es z.B. bei Bedarf einzelne TXOs direkt über RPC (gettxout) prüfen kann, ohne ganze Blöcke laden zu müssen. Auch BTCPay Server empfiehlt bei Nutzung eines geprunten Bitcoin-Nodes eher Core Lightning, da diese Implementation offiziell pruned Nodes unterstützt und damit zuverlässiger läuft (docs.btcpayserver.org). LND kann zwar ebenfalls mit Pruning funktionieren, erfordert aber sorgfältigere Konfiguration und Überwachung.
Beide Lightning-Implementierungen können mit einem geprunten Bitcoin Core betrieben werden, jedoch sollte man großzügig prunen (lieber einige Dutzend GB statt das Minimum), um eine zuverlässige Funktion sicherzustellen. Core Lightning wird von vielen als die bessere Wahl erachtet, falls man mit starkem Pruning arbeiten muss: (docs.btcpayserver.org), während LND bei knapper Blockhistorie eher zu Synchronisationsproblemen neigt (github.com). In jedem Fall sind offizielle Dokumentationen und Warnhinweise zu beachten, und man sollte im Zweifel eher mehr Blockchain-Daten vorhalten, insbesondere wenn der Lightning-Node nicht durchgängig online ist.
Fazit
Pruning ist eine smarte Möglichkeit, eine vollwertige Bitcoin-Node zu betreiben, ohne mehrere Hundert Gigabyte Speicher zu verbrauchen. Für viele Nutzer reicht die reduzierte Funktionalität vollkommen aus, solange man keine tiefergehenden Dienste wie Adress-Indexierung oder historische Analysen benötigt.
Wer jedoch Blockexplorer, Lightning-Dienste oder Electrum-Server betreiben möchte, muss auf eine vollständige, ungeprunete Node mit vollem Blockchain-Archiv setzen.
