Get it?
Discussion
Common now...
"Die Diskussion um OP\_RETURN im Bitcoin-Protokoll wird von Bitcoin-Core-Entwicklern als übertrieben abgetan. Sie behaupten, dass Bitcoin Knots schlecht gewartet sei und die Debatte lediglich technisches Rauschen darstelle. Doch was als unwichtig dargestellt wird, ist in Wirklichkeit Widerstand gegen eine gefährliche Veränderung der Protokollkultur.
Das Bitcoin-Protokoll wird schleichend von Entwicklern umgestaltet, die mit risikokapitalfinanzierten Projekten verbunden sind. Abweichende Meinungen werden zensiert, und Filtermechanismen werden entfernt, um Platz für deren Datenlast zu schaffen. Doch der Widerstand ist nun koordiniert, und es stehen Ankündigungen bevor, die dies verdeutlichen werden.
Bitcoin Knots ist kein Randprojekt; es basiert zu 99,9 % auf Bitcoin Core. Der Unterschied liegt in den Standardrichtlinien, nicht in der Architektur. Knots priorisiert Bitcoin als Geld, was es für diejenigen gefährlich macht, die andere Interessen verfolgen.
Die Behauptung von Core, dass Filter ineffektiv seien, ignoriert die Realität. In Wirklichkeit ist die Nutzung von Knots von 1 % auf über 8 % des öffentlichen Netzwerks gestiegen – ein Misstrauensvotum gegenüber dem Umgang von Core mit dieser Angelegenheit.
Core-Vertreter argumentieren, dass Filter nutzlos seien, da Spam direkt Miner erreichen könne. Das ist vergleichbar mit der Aussage, Schlösser seien nutzlos, weil Türen eingetreten werden können. Die meisten Angreifer nutzen weiterhin den Mempool; nur wenige benötigen direkten Zugang. Filter erhöhen die Hürde und schützen Bitcoin.
Filter stoppen nicht allen Spam, machen ihn jedoch teurer, inkonsistenter und weniger attraktiv. Deshalb drängen Projekte wie Citrea, Bitlayer und Alpen Labs darauf, sie zu entfernen. Sie streben den günstigsten und konsistentesten Datenpfad auf Layer 1 an, um parasitäre Sidechains zu bauen.
Es geht nicht nur um technische Richtungen, sondern darum, wessen Interessen Bitcoin Core dient. Wenn Core-Entwickler von denselben VCs finanziert werden, die auch diese Projekte unterstützen, und sie Protokolländerungen vorantreiben, die diesen Projekten zugutekommen, fällt das auf.
Folgt dem Geld: Brink finanziert Entwickler. Brink wird von Börsen und profitorientierten Akteuren unterstützt, die von „Bitcoin als Plattform“ profitieren. Viele Projekte, die die Erweiterung von OP\_RETURN vorantreiben, sind finanziell mit denselben Entitäten verbunden, die die Core-Entwicklung finanzieren.
Während dieser Debatte wurden Kritiker auf GitHub zum Schweigen gebracht. Threads wurden gesperrt, ACKs eingefügt und stillschweigend entfernt. Core hat keinen Konsens gewonnen, sondern ihn hergestellt. Die technische Diskussion wurde durch soziale Kontrolle unterdrückt und dann als „gelöst“ bezeichnet.
Die Divergenz zwischen Richtlinie und Konsens war nie ein Fehler; sie ermöglichte es Node-Betreibern stets, ihre Infrastruktur selbst zu bestimmen. Sie verleiht dem Netzwerk Resilienz. Core betrachtet diese Resilienz nun als Problem und schlägt vor, sie zu beseitigen.
Der Plan entfernt das OP\_RETURN-Limit und macht die Änderung für Benutzer nicht konfigurierbar. Dies entzieht Node-Betreibern die Wahlfreiheit, zwingt zur Weiterleitung unerwünschter Daten und verlagert die Kontrolle über die Transaktionsverbreitung von den Nutzern hin zu zentralisierten Voreinstellungen.
Die Projekte, die dies vorantreiben, sind nicht klein. Citrea benötigt 144 Bytes pro Transaktion allein für Betrugsnachweise. Alpen Labs und Bitlayer benötigen konsistenten Zugriff auf Layer 1 für ihre Ausführungsschichten. All dies sind datenhungrige Infrastrukturen, die für Spekulation gebaut werden, nicht für solides Geld.
Bitcoin erlebt eine bewusste Protokollverschiebung in aller Öffentlichkeit. Die Kultur von Core wurde von Personen kompromittiert, die Bitcoin als allgemeine Abwicklungsplattform und nicht als monetäres Netzwerk sehen. Sie gestalten die Mempool-Richtlinien um, um diese Verschiebung zu normalisieren und jeden Widerstand zum Schweigen zu bringen."
Das ist genau der emotionale und technisch inkorrekte Hype, gegen den ich versuche zu argumentieren. Danke für die Zusammenfassung.
A more accurate description:
That post ignores transactions which are unidentifiable as spam, yet are spam, because they are hiding their data as (fake) transactions. Which bloats the UTXO set. So, no, not convincing at all. And I though Jimmy would know better.
Jimmy knows better. These transactions only happen at that scale because the filters in core that are meant to deter them to a larger degree are broken for years and Core refuses to fix them. There was a PR by Luke in 2023 that proposed a fix and they locked it citing “controversy”. At the same time the filter for op return is working, as proven by Unhosted Marcellus. And the current PR is trying to nuke it.
Interesting. So how do you filter a series of TXs using small OP_RETURN payloads, or payload as signatures, or payload as raw multisig, or payload as scripts, or payload as any of the new things that VC backed scammers can and will come up with, when forced?
Seriously interested. I just don't think there's a good answer.
datacarriersize=0
Works in Knots. Doesn’t work in Core even if you manually set it to 0.
This is a good rule of thumb, but there are instances where it’ll not work or you don’t want it set to zero. In the spam filtration tab in knots there is a lot of optionality. New filters can be added/deployed a faster and more frictionless than spammers finding vulnerabilities of figuring ways to bypass them.
That creates two problems:
- the ones creating the filters become a trusted and central authority and can subsequently be attacked by the state
- VCs can stay solvent longer than the ones who update the filters, can stay motivated
Maybe try knots before you cry about it. The options knots has allow for you to make up your own set of filters so its self sovereign, and it might be hard for some bitcoin normies to understand but self sovereignity is the opposite of central authority. For central authority you can look at the boys from core, muting unwanted comments, paying someone to post a PR, stuf like that.
Vented enough? Cool. First of all, I tried knots. It's running on one of my nodes, and I mined with OCEAN for as long as my miner worked. I am also sympathetic to Luke and to his views. And I am also peeved about the GitHub comment closing/re-opening for ACK etc.
However, that changes nothing about the fact that filters are - very unfortunately - ineffective in trying to reach an optimal behavior of the overall network. And crying about it doesn't help either.
Great response, thanks mate!
Exactly 😉
Considering running nostr:nprofile1qqsve2jcud7fnjzmchn4gq52wx9agey9uhfukv69dy0v4wpuw4w53nqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcuseaka's Libre Relay.
Always an option
Are you implying that the private owner of that plot of land should be forced to remove the gate since to you apparently that doesn't serve any purpose?
Talking about force in FOSS development kind of disqualifies you, you know.
So what are we even all talking about?
A: "From next version, we will not support filtering txs for OP_RETURN size, maximalists won't like it but heh "
B: "Right we don't like it, if you don't keep the filters in at least as an option we will switch to Knots"
A: "Unwarranted criticism! [...] Just one dev! [...] Censorship! [...] UTXO bloat! [...] TRUST THE DEVS! [...] Not needed anyway! [... ] Not an option."
B: "Ok we move to Knots then"
A: "Haha look at you losers using filters that are useless"
B: "We won't be forced to go without them on our hardware"
A: "Duuhhhhh we never wanted to force you"
Exactly. FOSS. You choose. Core tried to set defaults that increase network efficiency, but nobody has to accept them. FOSS != FORCE