Diskussion wird insbesondere auf Github erfolgen
Prima 
dann kannst Du Dir für Schattenboxen die passenden Sparingspartner suchen, statt solche Dinge zu verbreiten:
Jeder kann Bitcoin forken, aber was passiert, wenn fast alle Nodes da draußen auf Konsensusebene frei bis zur Scriptsize-Limit Blöcke validieren und relayen, und ein paar Abweichler nicht?
Es ist ein Fehler diese Zensuridee weiter zu verfolgen, weil man sich in’s Uferlose verfranst. Aber das kennen wir ja mittlerweile aus dem bürgerlichen Leben ebenso.
Sich in einer Verbotskultur zu verfangen und sich in dieser geradezu idologisch fanatisch zu verlieren, scheint einen merkwürdigen Reiz für manche zu haben.
Dennoch ist diese Herangehensweise innovationsfeindlich und daher einfach eine schlechte Idee.
Es gibt bisher kein wirkliches Problem, und daher muss auch nichts gefixt oder „improved“ werden.
1 „Gefällt mir“
noch so ein schöner Vergleich, wie viel „Spam“ durch OP_RETURN größer 84 bytes entsteht. Ich poste die Bilder auch mal direkt, für diejenigen die kein X haben:
also hier sind die OP_RETURNS größer als 84 bytes markiert:
sieht man nicht so gut ne?dann hier mal das gleiche, aber wo alle OP_RETURNs ≤42 bytes weggelassen wurden:
und jetzt nur die oversized OP_RETURN Transaktionen die ≥84 bytes sind. Fällt euch was auf? Ja, solche großen OP_RETURNS wurden schon vor Bitcoin Core V30 in die Blockchain geschrieben.
Wenn man jetzt die superschlechte Woche nimmt vom 1.Dezember wo 23 oversized OP_RETURN outputs in die Chain geschrieben wurden, was um die 431 kB war, so machte das 0,043% der wöchentlichen blockspace aus.
wer hier von Spam redet, sorry, der labert einfach nur bullshit nach. Es ist ein Angriff auf Bitcoin und Luke ist der Rattenfänger, der die Leute belügt und nach seiner Pfeife tanzen lässt.
wer meinen Bildern nicht glaubt: hier ist der Link zur Blockchain-Analyse:
https://dune.com/murchandamus/opreturn-counts
2 „Gefällt mir“
Zum Thema gibt es wohl keine schnelle Lösung, hier noch ein erstmal abschließender Versuch einer Erläuterung der unterschiedlichen Bewertungen:
Die vor Core v30 in die Blöcke geschriebenen großen OP_return erfolgten durch die Miner, die diesen speziellen Spam-Dienst auch Fremden anbieten. Die oben aufgezeigte Argumentation zeigt (für Knots-Leute), dass die Spam-Filterung vor v30 durchaus funktionierte. Anmerkung, auch diese Möglichkeit des Spam wird mit dem BIP unterbunden.
Nun wird mit v30 dieser Platz bei OP_return durch die Bitcoin-Gemeinschaft für viel Spam eingerichtet. Externe Anwender können diese Öffnung als Einladung zur Nutzung verstehen. Aus dieser Situation ergibt sich die völlig unterschiedliche Bewertung zwischen den pro&contra Gruppen:
- die BIP-110-Leute befürchten nach dieser ‚formalen Freigabe des OP_return Speichers‘ eine nun auf uns zukommende, anrollende massive Nutzung dieses ‚neuen angebotenen Speicherplatzes‘ durch Bitcoin-fremde Anwendungen, während
- die Core-Leute wohl davon ausgehen, dass es durch v30 zu keinem wesentlich wachsenden Spam-Aufkommen kommen wird.
Ich sehe zwischen diesen Bewertungen kein argumentatives Zusammenkommen, obwohl nach meinem Verständnis keine Seite den Spam möchte.
Bei dem geringem TX-Volumen frage ich mich ja ob mehr Spam nicht sogar gut wäre.
Die Miner müssen ja auch von etwas leben.
Ihr HODL’t ja alle nur.
2 „Gefällt mir“
ich kann dir nur nochmal zu Herzen legen, sich die Graphen genauer anzuschauen, weil du das offensichtlich nicht gemacht hast. Bitcoin core v30 wurde am 10.okt.2025 released. Geh einfach mal auf die Seite und schau dir an was vor und was danach passierte und vor allem im Vergleich ≥84 bytes was Knots verhindern möchte und <84 bytes was überall laufen soll, also sowohl bei Knots als auch bei core v30. Und erkläre mir bitte dann wo die „massive Nutzung“ wie du es so nennst, zu verordnen ist.
Auf der Seite sind diese Kategorien in unterschiedlichen Farben dargestellt:
Ich gebe dir schon mal ein Hinweis: Sowohl im counts per week chart als auch im bytes per week chart, sind sie kaum wahrzunehmen. Um sie wahrzunehmen, musst du die OP_RETURN Transaktionen <84 bytes aus dem Graph ausschließen. Und während du das machst, schau dir bitte an was mit der y-Achse passiert 
„massive Nutzung“… Leute echt…
3 „Gefällt mir“
Scheinbar suchst Du nur nach Cheerleadern für den Fork, sonst würdest Du auf die Argumente und gut aufbereiteten Daten von @silentpredator eingehen.
Es gibt kein Problem mit Spam und es gibt kein Anzeichen für ein zukünftiges Problem.
4 „Gefällt mir“
Kann mir jemand von euch sagen wie Murch auf diese Daten kommt? Was an den Statistiken auf meiner geteilten Website anders analysiert wurde?
Wenn ich die Informationen auf meiner geteilten Website ansehe, dann ergibt sich von den Daten her schon ein Spam Problem. Spannend ist vor allem die Verteilung:
Financial: Blockspace 50-60%, Fees 90%
Non Financial: Blockspace 40-50%, Fees 10%
sind doch die gleichen Daten. Murch hat zischen der Größe der OP_RETURN Daten unterschieden. das kannst du auf deienr Seite auch machen.
Das bedeutet also das die Paar grossen OP_Return, Ordinals Ursache für etwa 40% des Blockspaces, in den letzten 3 Jahren sind.
Auf mich wirkt das ganze Ansinnen von Luke Dashjr wie so ein erster Schritt einer Langzeitstrategie, um Bitcoin zentralistischer und kontrollierbarer zu machen. Es fängt ganz langsam und harmlos an, kleine Einschränkungen gegen unerwünschte Daten. Was unerwünscht ist, entscheiden Leute wie Luke, versteht sich. Aber das wäre ja nur der Anfang. Wenn sich die Community dran gewöhnt hätte, würde man versuchen, immer größere Änderungen durchzusetzen. Irgendwann würden dann auch Vorschläge kommen, “geklaute” oder sonstwie aus Verbrechen stammende Bitcoin rückabwickelbar zu machen, anfangs vielleicht mit Mehrheitsentscheidungen (der Miner oder Nodes), am Ende dann aber z.B. mit Mehrheitsentscheidungen der Mining-Pools/-Firmen, also der CEOs, nicht der Teilnehmer in diesen Pools. Das wäre dann Mission Accomplished.
Es gibt viele Dinge, die man als idealistischer Weltverbesserer an Bitcoin verändern könnte, z.B. gibt es angeblich 140 Millionen Dust-UTXOs, das sind so UTXOs, die wie Spam über dem ganzen Netzwerk ausgeschüttet wurden und sich oft nur im Bereich 547 Sats bewegen (lange Zeit Minimalbetrag für eine Transaktion). Auf vielen sehr alten Wallets liegen 2-3, manchmal auch dutzende oder hunderte von diesen Dusts. Da könnte so ein Luke doch auch ankommen, nach dem Motto, das werden jetzt zu viele Daten, Blockchain wird zu groß, Netzwerk verstopft, lasst uns die konsolidieren, z.B. indem man bei Wallets mit größeren Beträgen die Dust-UTXOs mit einem größeren UTXO zu einem Wert zusammenfasst. Bei Wallets, wo sich das nicht lohnt, weil auch nach Konsolidierung nur ein paar tausend Sats auf der Wallet liegen würden, also unterhalb der üblichen Transaktionsgebühren, könnte man ja drüber nachdenken, die z.B. den Minern zuzuführen.
Neben den Dusts gibt es angeblich auch 4.6 Millionen Wallets mit Beträgen unter einem Dollar, die aber nicht durch Dusts zustandegekommen sind.
Man könnte sich auch mal fragen, welchem Zweck dienen diese Dusts. Ein Argument war ja, daß man damit interessante Wallets zwecks Verfolgung markiert. Das hab ich nie so ganz verstanden, heute wird spezielle Software oder Seiten wie Arkham Intel benutzt, da muss man nichts markieren, da trägt man interessante Wallets in eine lange Liste, Datei, etc ein. Es gibt auch diesen Begriff Dust-Attack, da sehe ich aber auch nicht wirklich, wie das sinnvoll funktionieren sollte. Man könnte noch irgendwas konstruieren, daß sich unter bestimmten Umständen rechtliche Verpflichtungen ergeben, wenn z.B. ein US-Amerikaner solche Eingänge auf seiner Wallet hat und die plötzlich wertvoll würden. In so einem Fall müssten die Eingänge dann bei der US-Steuer angegeben werden, auch ohne daß sie verkauft werden.
Und jetzt die Verschwörungstheorie zu Dusts: Was wäre, wenn diese Dusts nur ausgebracht wurden, um erst mal Sand ins Getriebe zu streuen und auszutesten, wie weit man Bitcoin damit schaden kann. Es werden ja heute noch Dusts verteilt, wenn auch nicht mehr so viele. Aber nehmen wir mal an, in ein paar Jahren gibt es doppelt soviel Dusts wie heute. Das würde einem selbsternannten Verbesserer wie Luke die Möglichkeit und Bühne geben, so eine zentralistisch angestossene Konsolidierung durchzudrücken. Ok, klingt alles vielleicht ein bisschen unrealistisch, da müsste dann ein Langzeitplan über xx Jahre dahinterstecken.
Das Spam-Problem hat eigentlich mit Taproot begonnen.
Die entscheidende Frage ist deshalb vielleicht nicht, ob die Gruppe, die den Spam möglichst verhindern will, der Angriffspunkt ist. Vielleicht liegt der eigentliche Angriffspunkt beim Update selbst, oder beim Verweigern von Verbesserungen. Also bei der Änderung, die es überhaupt erst möglich gemacht hat, grosse Datenmengen in diesem Ausmass auf die Blockchain zu schreiben (Libra Relay). Oder beim v30-Update, das anstatt Spam zu erschweren ihn für einen Angreifer sogar einfacher macht.
Hast du schon einmal darüber nachgedacht, dass vielleicht nicht die Reaktion auf den Spam das Problem ist, sondern die Änderung im Protokoll, die ihn technisch erst in diesem Umfang ermöglicht hat?
nein. eben nicht. schau dir dir Transaktionen ≥84 bytes an. Murch hat das hier gezeigt:
bei deinem Link kannst du das auch machen. Dafür musst du oben links anstatt auf Overview einfach auf OP_RETURN klicken, dann bekommst du das hier:
1 „Gefällt mir“
wie kommst du überhaupt auf 40%. also mit deinem Link komme ich nach 3 Jahren auf 0,7% . Und das ist nur der Anteil der großen OP_RETURNs bezogen auf Gesamt-OP_RETURNS. Bezogen auf den Blockspace insgesamt über die 3 Jahre, wären das noch viel weniger. Ist das ist auf deiner Seite jetzt nicht angegeben, aber bestimmt nochmal nen Faktor 10-100 weniger. Das ist absolut gar ncihts.
1 „Gefällt mir“
es gibt kein Spam-Problem.
es gibt keine großen Datenmengen.
das was Luke und seine Jünger betreiben ist der Angriff auf Bitcoin. Diese Leute spielen mit euren Gefühlen mehr ist das nicht.
2 „Gefällt mir“
Hier auf der ersten Seite. Es geht nicht nur um OP_RETURN. Ein grosser Teil des Spams kommt auch von Inscriptions.
Wenn du den BIP-Simulator anschaust, siehst du, welche Transaktionen bei einer Aktivierung nicht mehr gültig wären. Dort zeigt sich, dass etwa 30–40 % der Transaktionen betroffen wären. Der grösste Teil davon sind Inscriptions, mit denen Nutzer sich nicht an die normalen Transaktionslimits halten müssen. Wirklich grosse OP_RETURN-Transaktionen sind dagegen nur ein kleiner Teil des Spams, wie du bereits korrekt hervorgehoben hast.
Von einem „Angriff von Luke“ zu sprechen halte ich deshalb für falsch. Es ist eher eine unterschiedliche Philosophie, wie Bitcoin genutzt werden sollte.
Ich Frage mich eher:
Wenn Inscriptions kein Spam sind, welchen monetären Nutzen haben sie für Bitcoin? Und warum ist es gerechtfertigt, dass sie einen so grossen Anteil des Blockspace beanspruchen? Warum macht Core nichts dagegen?
Wenn 30–40 % des Blockspace durch OP_RETURN und Inscriptions belegt werden, finde ich es schwer nachzufolziehen, wie man das nicht als Spam-Problem betrachten kann.
das war deine Frage und die habe ich geklärt. Murch hat lediglich OP_RETURN analysiert, denn OP_RETURN hat ja nämlich den Stein ins Rollen gebracht bei der ganzen Diskussion. Es ging ja darum, dass die core devs den OP_RETURN-Limit aufgehoben haben und Luke und seine Jünger sind deswegen ausgerastet, weil das angeblich Spam verursacht. Das tut es nicht und da stimmst du mir schon einmal zu.
Inscriptions sind eine andere Geschichte, aber die Debatten zu Inscriptions liefen vor 2019-2021 ab, als es mit Taproot aktiviert wurde. Das war 2021 meine ich, also vor 5 Jahren. Die Debatte lief schon und die Leute haben sich dafür entschieden. Inscriptions sind auch nicht alles NFT und Bilder. Inscriptions sind einfach nur Anhänge. Wofür sie genutzt werden, sollte der community überlassen werden. In meinen augen sollte man Innovation nicht im Wege stehen. Wie ich schon in diesem thread zum 100x mal ausführe. Wer bist du/ich/wir zu wissen wofür andere Nutzer diese Anhänge brauchen. Wir müssen uns nicht allwissend über andere erheben, weil wir nicht alles wissen können. Meinst du du kennst alle potentiellen use-cases von solchen Anhängen?Vielleicht programmiert demnächst jemand einen guten 2nd-layer, was die scalability erhöht oder wat weiß ich. Innovation im Keim ersticken war noch nie eine gute Idee. Hört sich ziemlich kommunistisch an 
ja richtig. wir wollen, dass Bitcoin frei und zensurresitent bleibt und dass die Innovation nicht behindert wird, sondern freien Lauf hat während Luke zensieren möchte. Warum? Weil die chain zu schnell wächst? das ist absoluter Blödsinn. Die Limitierung des Blockspace verhindert ein zu schnelles Anwachsen. Und echten Spam wird man auch mit BIP110 nicht verhindern können. Also ist das ganze rumforken einfach nur ein Angriff von Luke selbst.
zusätzlich muss ich sagen, dass die Seite die du gepostet hast, einen bug hat. du selbst hast die time range auf 3 Jahre gestellt. jetzt schau mal auf die x-Achse. ein kleiner Tip: es ist etwas weniger als 3 Jahre :D
und solchen Daten vertraust du?selbst wenn es Inscriptions gibt, meine Argumentationsfolge von oben sollte eigentlich verständlich sein. ich sag ja, diese Leute spielen mit Gefühlen. Es gibt kein Problem, außer man macht sich eins, weil einem langweilig ist oder was weiß ich. Glaub mir, lass dich von denen nicht verblöden.
1 „Gefällt mir“
Ganz einfach: WEIL SIE DAFÜR BEZAHLEN UND BITCOINS BLOCKSPACE NUNMAL EIN FREIER MARKT MIT ANGEBOT UND NACHFRAGE IST.
2 „Gefällt mir“
Das kann ich nachvollziehen. Genau an diesem Punkt unterscheiden sich jedoch unsere Ansichten. Wenn man neue Technologien ausprobieren, oder experimentieren will, kann man das im Testnet machen. Das ist dafür gedacht und zudem deutlich günstiger.
Jede Änderung am Protokoll bringt ein Risiko mit sich. (Siehe Taproot) Wie viele echte Use-Cases gibt es auf Ethereum. Je komplexer der Code wird, desto abhängiger wird das System von wenigen Entwicklern, die ihn noch vollständig verstehen. Schon heute können nur sehr wenige Personen den gesamten Code wirklich überblicken. (auch ich) Wenn man sich vorstellt, wie das in 50 Jahren aussieht, steigt damit auch das Risiko für Korruption, oder Fehlentwicklungen einfach weil immer weniger Leute nachvollziehen können, was genau passiert.
Wenn tatsächlich ein überzeugender Use-Case entsteht, der Bitcoin als Zahlungsnetzwerk verbessert, kann man die Parameter immer noch anpassen und über einen Konsens-Change diskutieren. Vorallem da es vorerst auf 1 Jahr limitiert ist. Die meisten Anwendungen lassen sich jedoch ohnehin auf Second Layers wie Lightning umsetzen, oft sogar einfacher, günstiger und ohne den Base Layer zusätzlich zu belasten.
Wie viele zusätzliche Funktionen sollten überhaupt im Wert-Layer landen?
Deshalb halte ich einen konservativen Ansatz für sinnvoll. Lustigerweise bedeutet konservativ hier nicht, nichts zu ändern. Meiner Meinung nach bedeutet es eine Änderung zu machen, die zukünftige Änderungen schwieriger macht und Risiken im allgemein und durch unnötig hohe Parameter zu schliessen.
Das bleibt auch mit dem BIP so. Das Einzige, was das BIP macht, ist zu limitieren, wie viele Daten an eine Transaktion angehängt werden können. Nur weil ich mit meinem Private Key deine Bitcoins nicht versenden kann, würde ich das auch nicht als Zensur bezeichnen. Bitcoin definiert klare Regeln, und genau das Gleiche würde auch mit diesem BIP gelten. Jede Zahlung kann weiterhin ganz normal durchgeführt werden, solange sie nicht übermässig viele Daten anhängt.
Stimmt, das habe ich gar nicht bemerkt. Ich erinnere mich aber, dass im Podcast erwähnt wurde, dass die Daten nur bis zu einem bestimmten Zeitpunkt zurück aufbereitet wurden. Mein Fehler. Am grundsätzlichen Bild würde das vermutlich trotzdem nicht viel ändern ;)
das ist nur ein Anhang. Das macht keinen Code kompliziert. Und dieser Anhang wurde über Jahre auf den Testnetzen getestet. Du holst gerade etwas aus der Schublade, was bereits hinter uns liegt. Die community hat sich bereits dafür entschieden und deswegen wurde es implementiert. Das mit dem 2nd-layer war nur ein Beispiel. Anhänge können für alles mögliche genutzt werden. Und du fängst hier schon wieder an alle möglichen use-cases überblicken zu können und die Zukunft vorausschauen zu können. Ein Anhang macht den Code nicht komplizierter, aber er verküpft die Blockchain mit dem unbekannten X. Das ist der use case. Wie kann man so überheblich sein und meinen, diese Eigenschaft/Innovation im Keim ersticken zu müssen, obwohl kein Problem da ist.
das mit dem 2nd-Layer war nur ein Beispiel. Ich habe ebenfalls nicht alle möglichen use-cases im Kopf, weil ich nicht in die Köpfe von den anderen 8 Milliarden Menschen schauen kann.
- du siehst doch wie schwer es ist Konsensregeln zu verändern, wenn also jemand einen wichtigen use-case entwickeln sollte, könnte er daran scheitern
- wenn Anhänge von Anfang an verboten sind, arbeiten direkt viel weniger Leute eben an solchen Ideen. Warum sollte man an etwas arbeiten, was bereits verboten ist. Du siehst also, es hemmt Innovation.
- Es wurde bereits vor Jahren dafür abgestimmt, wir brauchen diese Debatte nicht schon wieder
Freier Markt. So viele wie die Leute möchten. Die Fees werden das regeln. Die Chain wird dadurch nicht schneller anwachsen, denn sie ist ja durch den Blocklimit begrenzt. Und selbst wenn dann jeder Block voll wäre - die Rechnung wurde hier im Forum schon 100x besprochen - wäre es nicht signifikant mehr. Die Dezentralität wäre damit nicht in Gefahr.
du willst Zensur betreiben. Es gibt jetzt schon Transaktionen mit use-cases, die nach BIP110 nicht mehr funktionieren würden. Die Leute müssten jetzt migrieren um das abzuwenden. Wünsche denen viel Spaß die im Koma liegen oder anderweitig davon nicht mitkriegen. Es wurde damals beschlossen, eingeführt, es schadet nicht - let’s go on to the future.
Ich klinke mich jetzt hier aus, aber ich verspreche euch, ich für meinen Teil, werde Zensur niemals befürworten und Innovation immer supporten. Vor allem, wenn sie bewiesenermaßen keinen Schaden verursacht und den Code nicht komplizierter macht. So hab noch sehr wichtige Dinge zu erledigen.
In diesem Sinne: „If you don’t believe me or don’t get it, I don’t have time to try to convince you, sorry“
2 „Gefällt mir“