Bitcoin Knots vs. Bitcoin Core – Unterschiede erklärt

In der Bitcoin-Community ist eine hitzige Debatte entbrannt: Soll die Bitcoin-Blockchain strikt nur für Finanztransaktionen genutzt werden, oder darf sie auch als Datenspeicher für beliebige Informationen herhalten? Hintergrund sind neuere Phänomene wie Ordinals (Bitcoin-NFTs), bei denen Nutzer Bilder oder Texte in Bitcoin-Transaktionen einbetten. Viele Bitcoiner betrachten solche Daten-Einbettungen als “Datenmüll” oder Spam, da sie Blockplatz fressen aber keinen monetären Zweck erfüllen.

Dieser Streit spiegelt sich auch in der Software-Wahl wider: Die allermeisten Bitcoin-Node-Betreiber verwenden die Referenzsoftware Bitcoin Core, während eine wachsende Minderheit auf die alternative Implementation Bitcoin Knots umsteigt. Beide Clients sind im Kern kompatibel, verfolgen aber unterschiedliche Philosophien im Umgang mit solchen „Spam“-Transaktionen. In diesem Artikel schauen wir uns Bitcoin Core vs. Bitcoin Knots genauer an – mit etwas Geschichte, den Unterschieden in der Mempool-Politik, warum Daten-Spam technisch überhaupt möglich ist, welche Vor- und Nachteile Filtermechanismen haben (Stichwort Lightning⚡) und wie letztlich die Transaktionsgebühren ein natürlicher Schutz gegen On-Chain-Spam bieten.

Was sind Bitcoin Core und Bitcoin Knots

Bitcoin Core ist die originale und meistgenutzte Bitcoin-Node-Software. Sie geht direkt auf Satoshi Nakamotos Ur-Client zurück und wird von einer großen Entwicklergemeinschaft gepflegt (thebitcoinway.com). Core setzt auf konservative Standards und Neutralität: Jeder gültige, regelkonforme Bitcoin-Transaction, die Gebühren zahlt, wird grundsätzlich akzeptiert und weiterverbreitet, ohne Bewertung ihres Inhalts.

Bitcoin Knots dagegen ist ein Fork (eine Abspaltung) von Bitcoin Core, der vom Entwickler Luke Dashjr betreut wird (reddit.com)(blog.bitfinex.com). Knots enthält fast den gesamten Code von Core, ergänzt aber einige erweiterte Einstellungen und strengere Richtlinien. Vor allem bietet Knots eingebaute Spam-Filter auf Mempool-Level – damit können Nodes z.B. Transaktionen aussortieren, die willentlich große Datenstücke ins Blockchain speichern (etwa via OP_RETURN) (blog.bitfinex.com). Knots gibt den Node-Betreibern also mehr Kontrolle, bestimmte „nicht-monetäre“ Transaktionen zu ignorieren, die sie für Verschwendung von Blockspace halten (blog.bitfinex.com). Außerdem aktiviert Knots standardmäßig Funktionen wie Replace-by-Fee (RBF) und andere Policy-Änderungen, die in Core teils nur optional sind (reddit.com).

Verbreitung: Bis vor kurzem war Knots ein Nischenclient – weniger als 5% der Nodes – doch 2025 ist seine Nutzung sprunghaft gestiegen (blog.bitfinex.com)(blog.bitfinex.com). Viele Umsteiger wollen ein Zeichen gegen „Datenmissbrauch“ setzen und sehen Knots als Möglichkeit, Bitcoin auf das Kerngeschäft „Peer-to-Peer Digital Cash“ zu fokussieren. Core-Befürworter hingegen pochen auf Offenheit und Kompatibilität – sie warnen davor, dass zu viele unterschiedliche Relay-Regeln das Netzwerk fragmentieren könnten. Wichtig zu betonen: Beide Programme folgen den gleichen Konsensregeln. Das heißt, ein Block der von einem Core-Knoten als gültig anerkannt wird, wird auch von einem Knots-Knoten anerkannt (und umgekehrt). Unterschiede bestehen nur in der Policy: also welche unbestätigten Transaktionen ein Node weiterleitet oder zurückweist. Diese feinen Unterschiede haben jedoch spürbare Auswirkungen für den Netzwerkbetrieb.

Unterschiedliche Mempool-Filter – was bedeutet das

Jede Bitcoin-Node verfügt über einen Mempool, eine lokale “Warteschlange” für unbestätigte Transaktionen. Wenn eine gültige Transaktion ins Netzwerk gesendet wird, landet sie in den Mempools der Nodes, wird von dort an weitere Nodes relayed, und wartet auf Aufnahme in einen Block durch Miner. Allerdings gelten für die Aufnahme in den Mempool sogenannte Standardness-Policies: Regeln, die über die reinen Konsensregeln hinausgehen. Diese Policies können z.B. Transaktionen ablehnen, die zwar gültig, aber ungewöhnlich sind – etwa extrem große Transaktionen, sehr viele Signaturen oder Ausgaben, die als „Daten-Träger“ dienen.

Bitcoin Core verwendet hier recht neutrale Standardeinstellungen. Zum Beispiel erlaubt Core standardmäßig eine OP_RETURN-Ausgabe (eine spezielle Transaktionsausgabe, die willkürliche Daten enthalten kann) von bis zu 83 Bytes (thebitcoinway.com)(thebitcoinway.com). Das reicht für kurze Nachrichten oder Verweise, ist aber absichtlich niedrig gehalten, um Missbrauch einzudämmen. Alles darüber hinaus würde Core nicht an andere Nodes weiterleiten. Core ist der Ansicht: Solange eine Transaktion gültig und gebührenzahlend ist, soll sie behandelt werden wie jede andere – das Netzwerk ist zensorfrei und anwendungsneutral (blog.bitfinex.com)(thebitcoinway.com). So sollen auch neue Nutzungsfälle experimentieren können, solange sie die Konsensregeln einhalten.

Bitcoin Knots hingegen verschärft einige dieser Standardregeln gleich ab Werk. Ein zentraler Unterschied: Knots stellt den datacarrier-Parameter, der OP_RETURN-Daten steuert, auf 0 (aus) (reddit.com). Das bedeutet, ein Knots-Knoten lehnt grundsätzlich jede Transaktion ab, die eine extra Daten-Ausgabe enthält (z.B. OP_RETURN), selbst wenn es nur ein paar Bytes Text sind. Solche TX gelangen dann nicht in seinen Mempool und werden nicht weitergeleitet. Darüber hinaus bietet Knots weitere Filtermöglichkeiten, etwa gegen bestimmte Protokolle wie Ordinals, Stamps, Runes (alles Methoden, NFTs oder Token-Daten in BTC-Transaktionen unterzubringen) oder sogar gegen Privacy-Transaktionen wie CoinJoins (blog.bitfinex.com)(blog.bitfinex.com). Die Philosophie dahinter: Bitcoin-Mempools sollen sauber bleiben, frei nach dem Motto “nur Geld, kein Unsinn”. Node-Betreiber können so ihren Ressourcenverbrauch senken (weniger Bandbreite/Plattenplatz für Spam) und ein Statement setzen, dass sie Bitcoin rein als Geldsystem sehen möchten (blog.bitfinex.com)(blog.bitfinex.com).

Diese unterschiedlichen Policies führen dazu, dass Bitcoin-Knoten nicht alle das gleiche Transaktionsset im Speicher haben. Ein konkretes Beispiel: Eine Ordinals-Transaktion, die ein Bild auf die Blockchain schreibt, hat oft eine große Witness-Datenmenge (mehrere Kilobyte). Bitcoin Core-Nodes würden sie in der Regel weiterleiten und minen, sofern die Gebühren bezahlt sind. Ein Bitcoin Knots-Node würde sie ablehnen (gar nicht erst in seinen Mempool nehmen oder weitergeben). Somit propagieren solche TX etwas langsamer oder über Umwege durchs Netzwerk – nämlich nur über die Core-Nodes. Hier stellt sich natürlich die Gretchenfrage: Kann man durch genügend Filterknoten diese “Spam”-Transaktionen ganz aus dem Netzwerk drängen? 🤔

Kann Bitcoin Knots „Datenmüll“-Transaktionen wirklich verhindern

Die kurze Antwort lautet: Nein, nicht wirklich. Zwar kann ein Knots-Knoten für sich beschließen, bestimmte TX als Spam nicht zu relayen – aber das verhindert nicht, dass diese letztlich doch in die Blockchain gelangen. Warum? Weil am Ende die Miner entscheiden, was in einen Block kommt. Und Miner sind in der Regel wirtschaftlich motiviert, nicht ideologisch. Sie nehmen die Transaktionen mit dem höchsten Gebührenertrag, egal ob darin ein Zahlungsauftrag oder ein JPEG steckt. Solange eine Transaktion den Konsensregeln entspricht und Gebühren zahlt, findet sich fast immer ein Miner, der sie aufnimmt. Viele Miner bieten inzwischen sogar direkte Kanäle (sogenannte “Transaction Submission” APIs) an, damit Kunden ihnen Transaktionen direkt einreichen können – vorbei an den öffentlichen Mempools (blog.bitfinex.com)(blog.bitfinex.com). Zum Beispiel hat der US-Miningpool Marathon mit “Slipstream” so einen Dienst geschaffen (blog.bitfinex.com). Fazit: Selbst wenn Eure eigene Node dank Knots bestimmte “Datenmüll”-TX nicht annimmt, können diese TX an anderen Stellen ins Netzwerk gelangen und gemined werden (blog.bitfinex.com). Sobald sie in einem gültigen Block enthalten sind, müssen auch Knots-Nodes den Block akzeptieren – die Daten sind dann unwiderruflich in der Blockchain und somit auch auf Ihrer Festplatte gespeichert (thebitcoinway.com).

Ein Reddit-Nutzer brachte es sehr treffend auf den Punkt: “Knots verhindert keinen Spam – du kannst deinen Mempool manipulieren wie du willst, aber die Miner werden trotzdem Transaktionen in Blöcke packen, wenn die Gebühren stimmen. Es ist ihnen egal, ob es Spam ist oder nicht. Am Ende erreicht dich der Spam sowieso, egal ob du Knots oder Core nutzt.” (reddit.com). Mit anderen Worten: Mempool-Filterung ist eher eine lokale Optik- und Effizienzmaßnahme, aber kein effektiver Netzwerkschutz. Jede Node speichert letztlich alle bestätigten Daten – ob man sie mag oder nicht, “like it or not” (thebitcoinway.com).

Allerdings argumentieren Knots-Befürworter, dass es trotzdem sinnvoll sei: Zum einen spare man lokal Ressourcen (kein Weiterleiten/Speichern bis zur Bestätigung). Zum anderen hofft man, dass wenn genug Knoten und vielleicht Miner filtern, “Spam”-Transaktionen unattraktiver werden. Tatsächlich gibt es mindestens einen kleinen Miningpool (Ocean), der Knots-Filter einsetzt und bewusst z.B. Ordinals-Daten nicht in seine Blöcke nimmt (blog.bitfinex.com). Dieser Pool wird u.a. von Luke Dashjr selbst mitbetrieben, aber er ist die Ausnahme – die meisten anderen Miner “lassen keine Satoshis liegen” und nehmen mit, was Geld bringt (blog.bitfinex.com). Somit bleibt Knots-Filterung vor allem ein symbolischer Protest gegen die „Datenflut“. Viele sehen darin eine Art „Votum mit den Füßen“: Node-Betreiber drücken aus, dass Bitcoin aus ihrer Sicht kein Allzweck-Datenspeicher sein sollte (blog.bitfinex.com)(blog.bitfinex.com). Aber faktisch aufhalten lässt sich eine motivierte Spam-Attacke damit nicht. Die ungeliebten Transaktionen fließen dann eben über die Nodes, die Core (ohne Filter) fahren, ins System und werden letztlich doch bestätigt (blog.bitfinex.com).

Warum ist Daten-Spam auf der Chain überhaupt möglich

Man könnte doch fragen: „Wenn die Bitcoin-Entwickler keine Bilder und Nachrichten auf der Blockchain wollen, wieso erlauben die Regeln sowas überhaupt?“ 🤷‍♀️ Die Wahrheit ist: Bitcoin war von Anfang an relativ offen gestaltet – es gibt Skriptbefehle und Funktionen, die missbraucht werden können, um beliebige Daten zu verewigen. Schon früh haben Leute kreative Wege gefunden, Botschaften in die Blockchain zu schreiben (sogar bevor OP_RETURN populär war, benutzte man z.B. sog. “bare multisig”-Outputs als Datenträger). Kuriositäten wie eine Heiratsantrag-Message oder die WikiLeaks-Nachricht 2016 wurden so ins Ledger gemeißelt (thebitcoinway.com)(thebitcoinway.com). Diese Gimmicks waren selten und klein (unter 80 Byte) – also kein echtes Problem.

Größere Spam-Wellen blieben lange aus, weil technische Limits und Kosten ein Hindernis waren. Beispielsweise wurde OP_RETURN 2014 eingeführt, aber mit striktem Limit (40 später 80 Bytes). Außerdem zählten solche Daten komplett zur 1 MB Blockgröße. Doch mit späteren Protokolländerungen hat Bitcoin ungewollt mehr Schlupflöcher für Datenspeicherung eröffnet:

• Segregated Witness (SegWit, 2017): Diese wichtige Skalierungs-Softfork lagerte Signaturdaten in einen separaten Blockteil (Witness-Bereich) aus und führte die Blockgewicht-Metrik ein. Dadurch wurde der effektive Block-Speicherplatz etwa auf 4 MB erweitert – zumindest für Witness-Daten (tokeninsight.com). Zudem erhalten Witness-Daten einen Rabatt bei der Gebührenberechnung (1 Byte Witness = 0,25 “Gewichtspunkte”). SegWit erhöhte also die Datenkapazität und senkte die Kosten pro Byte im Witness. Das heißt, wer kreative Hacks findet, um Nutzdaten in den Witness zu schmuggeln, kann viel mehr Informationen für viel weniger Gebühren unterbringen als vorher.
• Taproot (2021): Das Taproot-Upgrade brachte neue Skriptmöglichkeiten. Unter anderem vereinfacht es, große Datenblöcke im Witness unterzubringen, ohne an feste Limits zu stoßen (tokeninsight.com). Insbesondere erlaubt Taproot v1 „nicht-Standard“-Witness-Programme flexibler zu gestalten. Genau das nutzt die Ordinals-Methode aus: Durch einen Trick (einen OP_FALSE OP_IF … OP_ENDIF-Block im Skript) können beliebig große Daten ins Witness gepackt werden, ohne je ausgeführt zu werden (tokeninsight.com)(tokeninsight.com). So werden z.B. Bilddateien oder Texte als sogenannter Inscription in eine Taproot-Transaktion eingebettet. Praktisch ist die Grenze nur das Blockgewicht – theoretisch bis zu ~4 Millionen Bytes pro Block (4 MB) (tokeninsight.com). In der Praxis sind bisher Inscription-Größen von einigen Kilobyte bis ein paar hundert KB üblich, aber es wurde auch schon nahe ans Maximum gegangen. SegWit und Taproot haben diese Zweckentfremdung also erst ökonomisch rentabel gemacht (tokeninsight.com).
• Alternative Einbettungs-Tricks: Selbst wenn man OP_RETURN streng limitiert, fanden Nutzer Wege, Daten in anderen Strukturen zu verstecken. Beliebt war lange „bare multi-sig“: dabei legt man scheinbar einen Multi-Signatur-Output an, kodiert aber in den öffentlichen Schlüsseln die Payload-Daten – die Schlüssel selbst sind dann Dummy-Daten. Auch möglich: Viele winzige UTXOs mit bestimmten Mustern erzeugen (siehe das Phänomen BRC-20 Tokens 2023, wo Millionen minimaler Token-UTXOs entstanden (thebitcoinway.com)). Diese erhöhen sogar die UTXO-Datenbank für alle Nodes, was noch belastender ist als OP_RETURN (das per Flag als unspendable markiert und vom UTXO-Set ausgeschlossen wird) (thebitcoinway.com)(thebitcoinway.com). Mit anderen Worten: Versucht man eine Lücke zu schließen, weichen kreative Spammer eben auf eine andere aus. 🙃 Bitcoin ist ein permissionloses System – was nicht per Konsensregel verboten ist, das ist erlaubt. Und “wo ein Wille ist, ist auch ein Weg” – solange jemand bereit ist, Gebühren zu zahlen, kann er die Blockchain auch für Katzenbilder oder Liebesbriefe nutzen. Die Entwickler erkennen inzwischen selbst an: komplett verhindern ließe sich arbiträre Dateneinbettung nur durch eine Änderung der Konsensregeln, was jedoch einen hochumstrittenen Hardfork bedeuten würde (thebitcoinway.com). Daher geht der Trend eher dahin, Schadensbegrenzung zu betreiben (z.B. Daten ins OP_RETURN zu lenken, da diese Outputs prunebar sind und nicht die UTXO-Datenbank belasten (thebitcoinway.com)). Aber die Möglichkeiten werden denjenigen, die es wirklich darauf anlegen, kaum ausgehen.

Kurz gesagt: SegWit und Taproot haben Bitcoins Flexibilität und Kapazität erhöht – leider damit aber auch das Tor für mehr Daten-“Missbrauch” weiter geöffnet (tokeninsight.com). Dieses Zusammenspiel machte ab 2023 den massenhaften NFT-Spam auf Bitcoin (Ordinals, BRC-20 etc.) erst praktikabel. Die Community hat diese Nebenwirkung anfangs unterschätzt. Nun stehen wir vor der Frage: Akzeptieren wir Bitcoin als allgemeine “Immerwährende Datenbank”, oder halten wir strikt am Zahlungsnetzwerk-Charakter fest? Diese Kontroverse bildet den Kern von Core vs. Knots.

OP_RETURN – Schutzschild fürs UTXO-Set gegen Datenmüll

Damit jede Bitcoin-Node neue Transaktionen schnell prüfen kann, hält sie eine aktuelle „Bestandsliste“ aller noch nicht ausgegebenen Coins – das sogenannte UTXO-Set – permanent im Arbeitsspeicher. Je größer dieses Set wird, desto mehr RAM und Rechenleistung braucht eine Node, was den Betrieb verteuert und die Dezentralität schwächen kann.

Bevor 2014 OP_RETURN eingeführt wurde, versteckten manche Nutzer Daten in ganz normalen Ausgaben („bare multisig“). Solche Outputs sahen wie spendbare Coins aus und blieben daher dauerhaft im UTXO-Set, obwohl sie nur als Datenträger dienten. Das blähte die „Bestandsliste“ künstlich auf.

OP_RETURN löst genau dieses Problem: Ein Output mit diesem Skriptbefehl ist von vornherein nicht spendbar. Die Node weiß sofort, dass dieser Eintrag nicht ins UTXO-Set muss und kann ihn nach dem Empfang der Transaktion verwerfen. So bleibt das Set schlank, auch wenn Nutzer kleine Daten­schnipsel in die Blockchain schreiben.

OP_RETURN ist eigentlich als Schutzmechaismus eingeführt wurden – Daten dürfen weiterhin on-chain gespeichert werden, ohne dass das UTXO-Set durch Datenspam aufgebläht wird.

Nachteile der Mempool-Filterung – Lightning und andere Kollateralschäden

Die Idee, auf Node-Ebene bestimmte Transaktionen zu filtern, klingt für manche verlockend – doch sie hat Nebenwirkungen. Ein großes Problem: Wer definiert, was „Spam“ ist? Knots setzt hier harte Kriterien (z.B. “alles über 0 Byte OP_RETURN ist Spam”). Aber es gibt legitime Anwendungsfälle, die von solchen Regeln getroffen werden könnten.

Beispiel: Einige Privacy-Protokolle wie BIP47 PayNyms oder Samourai Whirlpool nutzen kleine OP_RETURN-Felder, um Nutzern zu helfen, sich abzustimmen oder Zahlungsinfos privat zu übermitteln (thebitcoinway.com).

Ein Knots-Knoten würde solche Transaktionen pauschal wegfiltern, obwohl sie aus Nutzersicht sinnvoll und legitim sind (sie verletzen keine Konsensregeln, zahlen Gebühren und dienen der Privatsphäre). Tatsächlich kam es 2023 zum Eklat, als ein von Luke Dashjr betriebener Filter-Miningpool began, Whirlpool-CoinJoins wegen eines 46-Byte-OP_RETURN nicht mehr zu minen (blog.bitfinex.com). Die Privacy-Community war empört und sah darin Zensur legitimer Zahlungen, während Luke das als notwendigen Anti-Spam-Schritt verteidigte (blog.bitfinex.com). Dieser Vorfall zeigt: Filter können Fehlalarm schlagen und wichtige Funktionen beeinträchtigen, die man gar nicht als Spam einstufen würde – je nach Perspektive.

Noch gravierender könnten Filter auf Lightning-Netzwerk-Transaktionen wirken. Das Lightning Network ist ein Second-Layer fürs schnelle Bezahlen, der aber im Ernstfall auf On-Chain-Transaktionen zurückgreift (z.B. beim Öffnen/Schließen von Kanälen oder beim Schlichten von Betrugsversuchen). Lightning-Transaktionen sind zwar normale Bitcoin-Transaktionen, enthalten aber teils ungewöhnliche Outputs. Speziell seit Einführung der Anchor Outputs (kleine „Anker“-Outputs von 330 Satoshi) nutzen LN-Commitment-Transaktionen absichtlich winzige Ausgabebeträge, um später eine Child-Pays-for-Parent (CPFP)-Fee-Erhöhung zu ermöglichen (lightspark.com)(lightspark.com). Aus Sicht der standard Policy sind solche Miniausgaben Dust und würden eigentlich nicht relayed – das Lightning-Protokoll brauchte hier also explizite Anpassungen im Bitcoin-Core-Mempoolcode, um zuverlässig zu funktionieren (bitcoin.stackexchange.com)(bitcoin.stackexchange.com). So wurde kürzlich eine “Ephemeral Anchors” Policy eingeführt, die es erlaubt, ein 0-Sat-Output mit 0 Fee zu propagieren, solange es sofort per Kindtransaktion mit Fee ausgeglichen wird (bitcoin.stackexchange.com)(bitcoin.stackexchange.com). Dieser Kniff war nötig, weil zuvor ein LN-Knoten unter Umständen seine eigene (zu niedrig bepreiste) Kanal-Closing-Transaktion nicht ins Netzwerk bekam, wenn die Fees plötzlich anzogen – selbst CPFP half nicht immer, da die Eltern-Transaktion alleine vom Mempool zurückgewiesen wurde (bitcoin.stackexchange.com). Mit Package Relay (Paket-Weiterleitung) wurde dieses Problem entschärft: Node akzeptieren jetzt 2-Transaktionen-Pakete (Eltern+Kind) gemeinsam, falls ihre kombinierte Fee ausreicht (bitcoin.stackexchange.com)(bitcoin.stackexchange.com).

Warum dieser technische Exkurs? Er zeigt: Lightning ist auf verlässliche Relay-Regeln angewiesen. Zu strikte oder inkonsistente Filterpolitik kann die Funktionalität von Second-Layer-Lösungen beeinträchtigen. Wenn z.B. ein Teil des Netzwerks bestimmte LN-Transaktionen fälschlich als Spam behandeln würde, könnten Lightning-Nutzer im Extremfall Probleme bekommen, ihre Kanäle rechtzeitig zu schließen oder die richtige Fee durchzusetzen – was Sicherheitsrisiken birgt. Glücklicherweise sind Core-Entwickler eng am Ball, um das zu verhindern. Aber bei alternativen Implementationen wie Knots muss man sich fragen: Werden dort all diese feinen Ausnahmen mitgetragen? Oder könnte es sein, dass ein Knots-Node im Eifer des Spam-Filterns mal eine Lightning-Transaktion nicht weiterleitet, weil sie z.B. einen ungewöhnlichen Output enthält? Diese Gefahr ist zumindest denkbar, wenn Filterregeln eigenmächtig verändert werden.

Zusammengefasst: Mempool-Filterung schafft Uneinheitlichkeit, was für ein globales Netzwerk immer heikel ist. Unterschiedliche Sichtweisen der Nodes auf “was erlaubt ist” können im schlimmsten Fall zu Split-Brain-Szenarien führen, wo ein Teil des Netzwerks Transaktionen “A” nicht kennt, die der andere Teil aber schon kennt und vielleicht mined. Aktuell ist das kein dramatisches Problem (die meisten folgen Core-Policy, Knots ist noch in der Minderheit), aber je mehr Nodes abweichende Filter fahren, desto mehr könnten sich Relay-Inseln bilden. Außerdem entgeht dem Netzwerk als Ganzes durch herausgefilterte Transaktionen auch ein Teil der Fee-Einnahmen – was ironischerweise langfristig schlecht für die Sicherheit sein könnte (blog.bitfinex.com). Denn Bitcoin ist darauf angewiesen, dass in Zukunft Transaktionsgebühren den Minern genug Anreiz bieten, weiter zu schürfen (wenn die Block-Subsidy immer kleiner wird). Wenn man also valide, zahlungsbereite Transaktionen unterdrückt – seien es NFTs, CoinJoins oder andere – verzichtet man auch auf Gebühren, die sonst zur Absicherung des Netzwerks beigetragen hätten (blog.bitfinex.com). Man schneidet sich möglicherweise ins eigene Fleisch, um ideologische Reinheit zu wahren.

Knots - Single Point of Failure Risko

Wenn man sich bei einer Software auf eine einzige Person als Hauptentwickler verlassen muss, spielen deren Sicherheits­praxis und bisherige Historie eine große Rolle. Im Fall von Bitcoin Knots ist das Luke Dashjr. Zu öffentlich bekannten Vorfällen bei ihm gehören unter anderem:

• Kompromittierter Signierschlüssel – ein Schlüssel, mit dem offiziell neue Versionen signiert werden, wurde einmal kompromittiert.
• Großer Diebstahl seiner eigenen Coins – Luke verlor eine sehr große Menge Bitcoin (ca. 200), weil die Coins auf einem Server lagen, der erfolgreich angegriffen wurde. Anschliessend verwendete er den Server weiter, bereinigte diesen von der Schadsoftware und setzte diesen nicht mal neu auf.

Diese Ereignisse bedeuten nicht, dass Luke in böser Absicht gehandelt hätte. Aber sie zeigen Schwächen in Prozess- und Schlüsselmanagement, die gerade dann relevant sind, wenn genau diese Person der alleinige „Gatekeeper“ für einen Node-Client ist.
Die naheliegende Frage: Wenn jemand seine eigenen über 200 Bitcoin nicht in einer Hardware-Wallet abgesichert hat – also eine Entscheidung, die für das eigene Leben finanziell extrem wichtig ist – warum sollte man dann blind darauf vertrauen, dass dieselbe Person beim Betrieb der eigenen Node stets perfekte Sicherheitsprozesse einhält?

Im Bitcoin-Ökosystem stützt sich die Integrität von Software-Releases auf sorgfältiges Schlüssel-Handling, reproduzierbare Builds und die gemeinsame Überprüfung durch die Community. Wird der Maintainer-Key kompromittiert, gerät genau der Mechanismus ins Wanken, auf den sich die Nutzer verlassen, um sicherzugehen, dass sie auch wirklich die Version ausführen, die sie zu installieren glauben.

Es geht hier nicht um einen persönlichen Angriff, sondern um eine Risikoabwägung:
Wer Knots einsetzt, ohne selbst sehr gründlich zu verifizieren, bündelt viel Vertrauen in sehr wenige Hände – und genau das ist in einem dezentralen System wie Bitcoin immer ein potenzieller Schwachpunkt.

Gebühren – der natürliche Schutzmechanismus gegen Spam

Gibt es abseits von Filtern und Regelwerken überhaupt einen Schutz gegen Spam auf Bitcoin? Ja – die Transaktionsgebühren! Bitcoins ökonomisches Design bringt automatisch eine Spam-Bremse mit sich: Jede Transaktion kostet Gebühren, und zwar umso mehr, je größer (datenlastiger) sie ist. Spammer zahlen also drauf. Will jemand z.B. 100 KB an Bilddaten ins Ledger schreiben, muss er entsprechend hohe Fees anbieten, um gegen normale Transaktionen zu konkurrieren (denn Miner priorisieren nach Gebührenrate). In Zeiten voller Blöcke wird das sehr teuer, sodass Spam finanziell unattraktiv wird (thebitcoinway.com).

Gebühren dienen somit als Marktmechanismus, der sicherstellt, dass Blockspace meist an die wirtschaftlich wichtigsten Transaktionen geht – alles andere wird herausgedrängt, außer der Spammer ist bereit, ein kleines Vermögen zu verbrennen (swissmoney.com). Wie bei E-Mail-Spam, wo Portokosten Spam verhindern würden, sorgt das Gebührenmodell dafür, dass man das Netzwerk nicht beliebig mit Nonsens fluten kann (swissmoney.com).

Bitcoin-Core-Entwickler argumentieren deshalb: Wenn eine Transaktion alle Konsensregeln einhält und die nötige Fee zahlt, dann ist sie per Definition kein Spam (thebitcoinway.com) – denn sie leistet ihren „Beitrag“ und verdrängt niemanden, der nicht mitbieten könnte. Sollte der Blockplatz durch unsinnige Daten belegt werden, werden echte Nutzer eben höhere Gebühren bieten, bis sich ein neues Gleichgewicht findet.

Diese Marktdynamik hat man 2017 bereits bei den Blocksize Wars gesehen: Blockspace ist ein begrenztes Gut, und Gebühren sind das Zuteilungsinstrument. Somit sind Transaktionsgebühren ein natürlicher Spam-Filter: Sie „stellen sicher, dass nur seriöse Transaktionen verarbeitet werden“, wie ein Guide es ausdrückt (swissmoney.com). Man könnte sagen: Wer für 4 MB Bilddaten pro Block dauerhaft zahlt, der subventioniert halt das Mining – und wenn es ihm das Wert ist, sei es drum. Sobald jedoch die Nachfrage für echte Finanztransfers steigt, werden solche Spielereien von selbst zurückgehen, da sie unerschwinglich werden.

Ein weiterer limitierender Faktor ist die Blockgrößenbegrenzung. Auch wenn durch SegWit/Taproot mehr Daten reinpassen, bleibt pro Block ein Hardlimit (~4 Mio Weight Units). Niemand kann das Netzwerk mit endlosen Daten zuspammen – pro 10 Minuten ist physisch Schluss. In dieser Zeit konkurrieren alle Transaktionen um den knappen Platz. Und genau hier greift wieder der Gebühren-Mechanismus: Unsinn landet nur drin, wenn kein sinnvollerer Nutzen diesen Platz haben wollte oder der Unsinnige mehr bezahlt als alle anderen. In beiden Fällen entsteht keine gratis Überflutung, sondern immer ein hoher Preis.

Fazit – Bitcoin zwischen Neutralität und Zweckbindung

Die Diskussion Bitcoin Core vs. Bitcoin Knots zeigt, wie unterschiedlich die Sichtweisen auf Bitcoin sein können. Die eine Seite (Core) betont Offenheit und Neutralität: Bitcoin ist ein neutrales Protokoll, das nicht zwischen “guten” und “schlechten” Transaktionen unterscheidet, solange sie den Regeln folgen und Gebühren zahlen (blog.bitfinex.com)(thebitcoinway.com). Dieses Lager sieht Filter eher kritisch und verweist auf Marktmechanismen und Protokoll-Weiterentwicklungen, um mit Missbrauch umzugehen. Die andere Seite (Knots) betont Reinheit und Effizienz: Bitcoin soll primär ein Wertübertragungsnetzwerk bleiben, kein “Datenmüllplatz”. Sie sind bereit, auf Node-Ebene einzugreifen, um die ihrer Meinung nach ursprüngliche Vision (Bitcoin als Geld) zu verteidigen – notfalls auch mit harten Filterschemen, die technisch an Zensur grenzen (blog.bitfinex.com)(thebitcoinway.com). Beide Gruppen wollen letztlich Bitcoin schützen, nur auf unterschiedliche Weise: durch Maximierung der Freiheit vs. Wahrung eines Zwecks.

Für normale Bitcoin- und Lightning-Nutzer ändert sich durch diesen “Node War” unmittelbar wenig. Es besteht keine Gefahr für Eure Coins – egal ob die Node-Mehrheit Core oder Knots nutzt, die Konsensregeln bleiben gleich und Ihre Transaktionen werden bestätigt (vorausgesetzt, Ihr zahlt ausreichende Gebühren). Allerdings lohnt es sich, die Debatte zu verfolgen, denn sie könnte langfristig beeinflussen, wie sich Bitcoin weiterentwickelt. Im schlimmsten Fall könnten extreme Unstimmigkeiten sogar zu Protokolländerungen oder Abspaltungen führen, aber soweit ist es (noch) nicht – bislang handelt es sich um eine Policy-Differenz, die jeder Node-Betreiber für sich entscheiden kann.

Interessant ist, dass die Knots-Welle auch positive Effekte haben kann: Mehr Vielfalt bei den Node-Implementierungen könnte die Dominanz von Core verringern und das Netzwerk dezentraler und resilienter machen (blog.bitfinex.com). Solange die Konsensbasis gleich bleibt, ist ein gewisses Maß an Wettbewerb vielleicht gesund. Letztlich erinnert die Situation an die Blocksize-Debatte 2017: unterschiedliche Visionen prallen aufeinander, und durch aktives “Mitstimmen” der Nutzer (in dem Fall via Node-Auswahl) wird sich zeigen, wohin die Reise geht (blog.bitfinex.com)(blog.bitfinex.com). Bitcoin hat schon oft bewiesen, dass es in solchen Diskursen am Ende gestärkt hervorgehen kann.

Zusammengefasst: Bitcoin Core und Bitcoin Knots stehen stellvertretend für zwei Philosophien – Neutralität vs. Selektivität. Daten-Spam auf der Blockchain ist technisch möglich geworden (SegWit/Taproot), aber die Gebühren sorgen dafür, dass er nie überhandnimmt. Node-Filter wie in Knots können im kleinen Rahmen ein Zeichen setzen und lokalen Traffic verringern, doch sie sind kein Allheilmittel und bringen Trade-offs (von verpassten legitimen TX bis hin zu komplexerer Netzwerktopologie). Ob Bitcoin am Ende eher dem “Code is law”-Prinzip (jede gültige TX ist willkommen) folgt oder sich stärker als zweckgebundenes Finanzsystem definiert, wird die Zukunft zeigen. Für technisch interessierte Laien gilt jedenfalls: Man muss nicht in Panik verfallen (thebitcoinway.com). Eure selbst verwalteten Bitcoins sind sicher, egal ob gerade JPEGs oder andere Daten über die Chain gejagt werden. Die Blockchain ist groß genug für allerlei Kuriositäten – und mit Lightning haben wir ja zum Glück einen Weg, die wichtigen Zahlungen schnell und kostengünstig off-chain abzuwickeln, weitgehend unbehelligt vom Treiben auf der Base-Layer. In diesem Sinne: Keep calm and HODL on! 🧘‍♂️