Die Begrenzung beliebiger Daten ist ein gefährlicher Einstieg in Protokollzensur. Die Stärke von Bitcoin liegt darin, Nutzer und Anwendungsfälle nicht zu diskriminieren.
Live estimate to the BIP-110 fork block, following the same countdown logic used by jlopp.github.io/knotzi-death-march.
Bitcoin ist als neutrales Transportrohr konzipiert. Wenn bestimmte Daten als "Spam" definiert werden, bringt BIP-110 subjektive menschliche Moral in die Basisschicht ein. Wenn wir heute Bilder filtern, was filtern wir morgen?
Quelle: Adam Back (Blockstream) → Vollständige Argumentseite →Wenn die Blocksubvention gegen null geht, muss Bitcoin auf Gebühreneinnahmen setzen. Inscriptions haben den Minern bereits über 500 Millionen US-Dollar gezahlt. BIP-110 streicht diese Einnahmen und macht das Netzwerk anfälliger für 51-%-Angriffe.
Quelle: Berichte zur Miner-Sicherheit → Vollständige Argumentseite →Filter stoppen Daten nicht, sondern drängen sie in den Untergrund. BIP-110 fördert "Out-of-Band"-Zahlungen, bei denen Nutzer Miner privat für die Aufnahme von Daten bezahlen. So entsteht ein zentralisierter, intransparenter Markt für Blockspace.
Vollständige Argumentseite →"Es ist ein Lynchmob-Versuch, Änderungen ohne Konsens durchzudrücken... BIP-110 wäre ein Angriff auf Bitcoins Glaubwürdigkeit als neutraler Wertspeicher."
Die technischen Einschränkungen des Vorschlags bergen Risiken, die über die bloße Entfernung von "Spam" hinausgehen.
Die Begrenzungen der Script-Tree-Tiefe, die Inscriptions stoppen sollen, sind dieselben Werkzeuge, die für BitVM und fortgeschrittene Smart Contracts genutzt werden. BIP-110 könnte unbeabsichtigt die Zukunft der Bitcoin-Skalierung blockieren.
Quelle: Kritik von Jameson Lopp → Vollständige Folgenseite →Eine rückwirkende Änderung dessen, was als "standard" gilt, kann vorab signierte Transaktionen oder timelocked Wallets unbrauchbar machen. Kritiker sehen darin eine erzwungene Enteignung von Nutzereigentum.
Quelle: Analyse von The Bitcoin Manual → Vollständige Folgenseite →Auf Basis von Jason Hughes' Notizen an Miner vom 15. Juli 2026 konzentrieren sich diese Einwände darauf, was BIP-110 für Blockproduzenten, Gebührenfindung, Koordination und die langfristige politische Angriffsfläche von Bitcoin verändert.
BIP-110 versucht eine Form der Payload-Einfügung zu blockieren, doch willkürliche Daten können in andere Script-Konstruktionen und Transaktionsmuster ausweichen. Miner tragen damit Koordinationsrisiko, ohne dass die zugrunde liegende Nachfrage verschwindet.
Quelle: Jason Hughes, Notizen an Miner →Wenn öffentliches Relay und Wallet-Tools manche Transaktionen ablehnen, können große Nutzer diesen Pfad umgehen und direkt mit Minern oder Pools verhandeln. Das Ergebnis ist weniger transparente Gebührenfindung und mehr Vorteil für Insider.
Quelle: Jason Hughes, Notizen an Miner →Sobald ein Soft Fork genutzt wird, um eine unerwünschte Blockspace-Nutzung zu verbieten, hören künftige Argumente auf, rein technisch zu sein. Miner werden zum Druckpunkt jeder neuen Kampagne darüber, was Bitcoin erlauben sollte.
Quelle: Jason Hughes, Notizen an Miner →Ein umstrittener Rollout zwingt Miner und Pools dazu, zu erraten, welche Chain gewinnt, wie Börsen reagieren und ob das Reorg-Risiko steigt. BIP-110 ist nicht bloß ein Policy-Statement, sondern ein operatives Risikoereignis.
Quelle: Jason Hughes, Notizen an Miner →Nachfrage, die Gebühren zahlt, bleibt Nachfrage, auch wenn manche Nutzer die Anwendung auf dem Blockspace nicht mögen. Ein Überschreiben dieses Marktsignals durch soziale Präferenzen schwächt die Glaubwürdigkeit von Bitcoins neutraler Inklusionsauktion.
Quelle: Jason Hughes, Notizen an Miner →Je stärker Bitcoin auf Sonderfilter, privaten Orderflow und Koordination über umstrittene Chains angewiesen ist, desto mehr verlagert sich der Vorteil zu großen Pools mit tieferen Beziehungen und besserer juristischer oder kommunikativer Position.
Quelle: Jason Hughes, Notizen an Miner →Einige der klarsten öffentlichen Kritiken aus Blogs, Berichterstattung und Online-Kommentaren.
In seinem Essay vom 23. Februar 2026 argumentiert Jameson Lopp, dass BIP-110 das Risiko eines Chain-Splits erhöht, Randfall-Funds einfrieren kann, künftige Upgrades einschränkt und willkürliche Daten trotzdem nicht stoppt, weil Nutzer die Regeln umgehen können.
Lesen: A Layman's Guide to BIP-110 →Die Berichterstattung über Adam Backs X-Kommentare stellt BIP-110 als gefährlicher dar als das Problem, das es lösen soll: Er warnt, dass es Bitcoins Glaubwürdigkeit beschädigen und durch Konsensregeln einige UTXOs einfrieren könnte.
Lesen: Bericht über Adam Backs Opposition →The Bitcoin Manual erklärt, dass eine UASF Miner unter Druck setzen kann, betont aber auch den Hauptnachteil: Wird die wirtschaftliche Unterstützung überschätzt, kann BIP-110 eine Minderheitskette auslösen, Liquidität spalten und Koordinationsfehler im Ökosystem erzeugen.
Lesen: What Is BIP-110? →Wenn BIP-110 einen umstrittenen Chain-Split ohne Replay Protection auslöst, kann dieselbe Transaktion auf beiden Chains gültig sein. Das öffnet die Tür für versehentliche Replays, Verwirrung bei Einzahlungen, gefälschte Wallet-Hilfe und Double-Spend-artigen Betrug gegen Nutzer und Börsen.
Lesen: Lopp zu Split- und Replay-Risiken →Lopp zitiert Andreas Antonopoulos mit dem Argument, dass ideologische Reinheitsspiralen in Selbstparodie enden. In dieser Lesart ist BIP-110 weniger ein technischer Fix als ein politischer Versuch, Bitcoin-Nutzungen zu verdrängen, die einigen Fraktionen missfallen.
Lesen: Lopp zitiert Andreas zur Reinheitspolitik →Lopp verweist außerdem auf Murchs öffentlichen Thread, der die Behauptung zurückweist, BIP-110 könne sich nach einer Aktivierung mit Minderheits-Hashrate sicher durchsetzen. Diese Kritik richtet sich direkt gegen die Vorstellung eines sauberen, konfliktfreien Rollouts.
Lesen: Lopp verweist auf Murchs Widerlegung →In seinem Artikel vom 23. September 2025 argumentiert Lopp, dass Knots ein grundlegendes Vertrauensproblem erbt, weil Binaries weiterhin ueber eine Infrastruktur verteilt wurden, die er als kompromittiert beschreibt. Der Punkt ist schlicht: Wenn die Release-Hygiene schwach ist, sollen Nutzer einer riskanteren Software-Pipeline vertrauen.
Lesen: It's Knot a Serious Project →Lopp kritisiert Knots ausserdem als undurchsichtigen Fork mit nur einem Maintainer: Die Merge-Historie ist schwerer zu auditieren, Merge-Commits sind nicht so signiert wie ueblicherweise bei Bitcoin Core, und Upstream-Review uebertraegt sich nicht sauber. Das ist wichtig, weil umstrittene Konsensaenderungen mehr Pruefung bekommen sollten, nicht weniger.
Lesen: Lopp zum Software-Lebenszyklus von Knots →Ein weiterer Strang in Lopps Artikel ist, dass die Knots-Governance nicht nur technisch umstritten, sondern auch politisch aufgeladen ist: Er verbindet das Projekt mit Feindseligkeit gegenueber Mixing, Privacy-Tools und sogar mit Kollateralschaeden fuer Systeme wie Whirlpool und Lightning. Das fuegt ein breiteres Oekosystemrisiko hinzu, das ueber die reine BIP-110-Regelaenderung hinausgeht.
Lesen: Lopp zu Privacy und Oekosystem-Folgen →In seinem X-Beitrag vom 15. Juli 2026 nennt Michael Saylor BIP-110 einen „Bitcoin Iatrogenic Proposal“: eine Behandlung, die Schaden verursacht. Der Einwand lautet, dass eine Änderung der Bitcoin-Konsensregeln gegen unerwünschte Daten schädlicher sein könnte als das Problem, das sie lösen soll.
Lesen: Michael Saylor auf X →Saylor argumentiert, es gebe für Bitcoin größere Gefahren als Spam, und die Umwandlung dieses Streits in eine Konsensänderung sei das eigentliche Risiko. BIP-110 würde derzeit gültige, gebührenzahlende Transaktionen ungültig machen und einen schädlichen Präzedenzfall schaffen.
Lesen: Michael Saylor auf X →In seiner verwandten Nachricht weist Saylor Gebühren, Nodes, Minern und Haltern getrennte Rollen zu. Protokolländerungen müssten überwältigende Zustimmung erhalten, damit schlechte Ideen scheitern, bevor sie Bitcoin schaden können.
Lesen: Michael Saylor auf X →DathonPwn berichtet von einem möglichen Konsensfehler bei einem späten Upgrade auf BIP-110. Im geschilderten Szenario behalten Nodes, die von älterer Software aktualisiert wurden, ihre bestehende Chain-History, während frisch installierte BIP-110-Nodes dieselbe History ablehnen. Dadurch droht ein versteckter Chain Split.
Lesen: DathonPwn auf X →Der gemeldete Fehler ist ernst, weil dieselbe historische Chain einheitlich bewertet werden muss. Akzeptiert ein Upgrade im laufenden Betrieb eine History, die eine Neuinstallation ablehnt, könnten Betreiber unwissentlich Nodes betreiben, die sich darüber unterscheiden, welche Chain gültig ist.
Lesen: DathonPwn auf X →Der Hinweis betont eine Grundanforderung an Konsenssoftware: Ein Node mit Upgrade im laufenden Betrieb und ein Node mit frischer Synchronisierung müssen denselben Konsenszustand erreichen. Scheitert diese Eigenschaft, schafft BIP-110 genau dann operative Unsicherheit, wenn das Netzwerk verlässliche Koordination benötigt.
Lesen: DathonPwn auf X →