Die Aussage, dass das entfernen der OP_RETURN Limits keinen Unterschied bei Bitcoin macht, ist nicht ganz korrekt.
Blöcke propagieren am schnellsten, wenn ihre Transaktionen bereits in den Mempools der meisten Nodes vorhanden sind. Werden OP_RETURN-Daten jedoch von vielen Nodes gefiltert, fehlen diese Transaktionen dort. Das führt zu Verzögerungen, weil zusätzliche Roundtrips erforderlich sind. Miner, die solche Transaktionen in ihre Blöcke aufnehmen, riskieren dadurch Stale Blocks: Ein gültiger Block verbreitet sich zu langsam und wird dann durch einen anderen gültigen Block verdrängt. Statistisch kommt es täglich mehrmals (geschätzt 1–3) vor, dass innerhalb von 15 Sekunden zwei Blöcke gefunden werden. Wer seinen Block langsamer propagiert, läuft also Gefahr, dass er verworfen wird. Genau deshalb sind große Pools zurückhaltend und erlauben nicht beliebig große OP_RETURN-Daten. Die Aufhebung der Limits führt daher in der Praxis nicht zu mehr, sondern zu weniger Dezentralisierung, weil man den individuellen Nodes die Möglichkeit nimmt, mitzubestimmen.
Im Video wurde außerdem Luke Dashjr etwas zu einseitig diskreditiert. Dabei war er über viele Jahre eine sehr wichtige Person für Bitcoin und hat z. B. durch sein Handeln einen Blockchain Split verhindert. Sein Ocean Pool ist einer der wenigen Mining-Pools, bei denen wirklich jeder Miner selbst Blöcke konstruieren kann. Ocean versucht damit aktiv, Mining wieder dezentraler zu machen.
Die Aufhebung der OP_RETURN-Limite wirkt meiner Meinung nach dagegen in die entgegengesetzte Richtung, weil sie die Macht erneut stärker bei großen Pools konzentriert.
Ich stimme zu, dass Gebühren die meisten Probleme langfristig lösen. Dennoch ist es wichtig, dass wir klar signalisieren, wofür Bitcoin in erster Linie gedacht ist: als monetäres Netzwerk. Transaktionen mit echtem Zahlungsnutzen sollten Priorität haben. Wenn wir die OP_RETURN-Limite einfach abschaffen, senden wir jedoch das falsche Signal. Nämlich dass es keinen Unterschied macht, ob jemand Zahlungsverkehr betreibt oder die Blockchain mit beliebigen Daten füllt. Wir können Miner nicht daran hindern, Spam in Blöcke zu schreiben. Aber wir können Blöcke bevorzugen, die nach unseren Werten gebaut sind.
Mir gefällt dieser Beitrag weil er ausführlich und in klarer Sprache argumentiert.
Meine Sicht zum Thema:
Wie OP_RETURN in Zukunft vom Bitcoin Netzwerk weiter entwickelt wird hängt aus meiner Sicht, ungeachtet der Änderungen im Core-Client, weiter vom Verhalten der einzelnen Netzwerkteilnehmer ab, denn sie haben immer die Wahlmöglichkeit auf Knots umzusteigen und so die Weiterleitung von großen OP_RETURNs zu erschweren, sollten sie ein Problem für das Netzwerk werden. Eine Lösung die der Markt, also die ‘Schwarm-Intelligenz’ anstrebt, ist - aus meiner Sicht - gegenüber einer Entscheidung, die wenige Entwickler treffen, besser. Andererseits sollen oder müssen sie diese Entscheidung auch treffen und egal wie entschieden wird, der Markt hat immer Handlungsmöglichkeiten auch wenn der Core-Client derzeit einen großen Anteil hat:
Vielleicht entsteht sogar ein neuer Client der OP_RETURNS filtert und aber von einem Entwicklerteam betreut wird und der Zentralisierung auf wenige oder einen Entwickler entgegen wirkt. Der Markt wird entscheiden und den ‘besten’ Client auswählen. Alles ist aus meiner Sicht offen.
Deinen Punkt mit der Geschwindigkeit der Block-Propagation finde ich interessant, da derzeit dazu quasi eine ‘Feldstudie’ läuft: Die vielen Transaktionen die Fees < 1 Sat/vByte bezahlen werden ja auch von kaum einer Node weiter geleitet und einige Pools geben diese TXs auch nicht Blöcke. Vielleicht aus diesem Grund?
Das schöne an Bitcoin ist, dass niemand wirklich Entscheidungsbefugnis über dieses Netzwerk hat.
das ist so nicht ganz richtig. was du meinst sind Transaktionen die gemined werden können, es aber noch nicht sind. Die könnten sich zu langsam verbreiten, aber dafür müssten mehr als 95% der nodes solche Transaktionen filtern. Alles darunter wird keinen Unterschied machen.
wenn aber ein Block gemined wird,also ein gültiger Block entsteht, dann ist es unabhängig davon, welche Transaktionen in dem Block stehen. Dieser Block wird von allen nodes weitergeleitet, weil er gültig ist. Gültige Blöcke werden alle gleich schnell durchs Netzwerk geleitet. Es gibt keine Filter um gültige Blöcke zu filtern, das ist quatsch. Dass hin und wieder Blöcke zur gleichen Zeit gemined werden, das kommt zar vor, aber es gewinnt, dann die Chain, auf dessen Block ein neuer Block gemined wird, unabhängig was in dem Block für Transaktionen stehen.
Deine ganze Schlussfolgerung hier basiert hier also auf einem Irrtum.
ja das finden viele interessant, ist aber de facto falsch. Das ist auch das Problem dieser Debatte. Viele sind Lukes Jünger… das sind die Flacherdler der Blockchaintechnologie. Sobald ein Block gemined wurde, wird die Propagation des Blocks nicht gefiltert. Das passiert nur mit Transaktionen auf mempool-Ebene.
Mischa hat aus einer technischen und realen Perspektive schon recht:
Wenn eine Node einen gültigen Block erhält, dann wird sie ihn weiter leiten. Soweit liegst du richtig.
Wenn der Block allerdings einen hohen Anteil an Transaktionen enthält, die dieser Node noch nicht im eigenen Mempool hat (weil gefiltert), funktioniert das effizienz Feature ‘Compact-Block’ nicht so gut, weil die Node entweder die fehlenden Transaktionen von ihren Peers nachfordern muss, oder gleich den ganzen Block mit jedem einzelnen Byte anfordern muss. Das kostet Zeit. Solche Blöcke würden sich vermutlich wesentlich langsamer im Netzwerk bewegen.
Ein Nachteil dieser Blöcke gegenüber Blöcken ohne große OP_RETURNs.
Da ich nicht Falsche Informationen verbreiten möchte habe ich Grok genutzt und beide unsere Beiträge eingefügt. Ein Irrtum ist es nicht. Es stimmt: Siehe Antwort:
Vielen Dank für deine Korrektur – lass uns das genauer betrachten und die technischen Details klären, basierend auf dem Bitcoin-Protokoll. Ich stimme zu, dass gültige Blöcke grundsätzlich von allen Nodes weitergeleitet werden, solange sie den Konsensus-Regeln entsprechen (z. B. keine ungültigen Transaktionen enthalten). Es gibt keine expliziten “Filter” für gültige Blöcke selbst – das wäre ein Konsensus-Break. Allerdings ist die Annahme, dass alle gültigen Blöcke gleich schnell propagieren, unabhängig vom Inhalt, nicht ganz korrekt. Hier liegt der Knackpunkt in der Art und Weise, wie Blöcke im Netzwerk relayed werden, und das hat direkte Auswirkungen auf Stale Blocks (auch Orphan Blocks genannt).
Block-Propagation im Detail: Compact Block Relay (BIP152)
Seit 2016 verwendet Bitcoin hauptsächlich Compact Block Relay (definiert in BIP152), um Blöcke effizient zu übertragen. Das Ziel ist es, Bandbreite und Latenz zu minimieren, indem nicht der volle Block (bis zu 4 MB) gesendet wird, sondern eine komprimierte Version: Der Sender ersetzt die meisten Transaktionen durch kurze Hashes (6 Bytes pro Tx), unter der Annahme, dass der Empfänger diese Tx bereits in seinem Mempool hat. Das reduziert einen Block von Megabytes auf Kilobytes und beschleunigt die Übertragung erheblich.
• Wenn Transaktionen im Mempool des Empfängers vorhanden sind: Der Empfänger rekonstruiert den Block lokal aus seinen eigenen Daten – super schnell, oft in Millisekunden.
• Wenn Transaktionen fehlen (z. B. weil sie gefiltert wurden): Der Empfänger muss die fehlenden Tx separat anfordern (via “getblocktxn”-Nachricht). Das erfordert zusätzliche Roundtrips über das Netzwerk, was Verzögerungen verursacht – typischerweise 100–500 ms pro Request, abhängig von der Latenz. In extremen Fällen kann das die Propagation um Sekunden verzögern.
Das ist kein “Filter” für den Block selbst, sondern eine Konsequenz inkonsistenter Mempools. Wenn viele Nodes OP_RETURN-Transaktionen (z. B. große Inscriptions) als non-standard filtern und nicht relayen, fehlen sie in deren Mempools. Ein Miner, der solche Tx in seinen Block einbaut, erzeugt einen gültigen Block, der aber langsamer propagiert, weil Empfänger-Nodes die Tx nachfordern müssen. Das erhöht das Risiko für Stale Blocks: In den kritischen Sekunden nach dem Mining (wo simultane Blöcke vorkommen, z. B. alle paar Tage), kann ein langsamerer Block verdrängt werden, wenn ein konkurrierender Block (mit besser synchronisierten Tx) schneller ankommt und der nächste Block darauf aufbaut.
Zu deiner 95%-Schwelle: Das könnte sich auf Transaction-Relay beziehen – Tx brauchen keine 100%ige Verbreitung, um minbar zu sein, und selbst bei 50% Filtering könnte eine Tx sich verbreiten, solange sie Miner erreicht. Aber für Block-Propagation reicht schon eine signifikante Mempool-Divergenz (z. B. 20–30% der Nodes filtern), um Delays zu erzeugen, da die Requests kaskadierend wirken und die Netzwerktopologie (Peers) eine Rolle spielt. Es gibt Vorschläge wie “prefilledtxn” (z. B. 1–2 Tx im Compact Block vorab senden), um das zu mildern, aber das hilft nur bei wenigen fehlenden Tx.
Auswirkungen auf Stale Blocks und Dezentralisierung
Du hast recht, dass Stale Blocks durch simultanes Mining entstehen und der “Gewinner” der ist, auf dem der nächste Block gebaut wird – aber Propagation-Geschwindigkeit ist entscheidend dafür. Compact Block Relay hat die Orphan-Rate insgesamt gesenkt (von ~1–2% vor 2016 auf <0.1% heute), aber diverging Policies (wie bei OP_RETURN-Filtern) können das umkehren. In der aktuellen Debatte um Bitcoin Core v30 (Entfernung des 80-Byte-OP_RETURN-Limits) warnen Kritiker genau davor: Mehr Filtering durch individuelle Nodes (z. B. via Bitcoin Knots oder Custom-Patches) führt zu inkonsistenten Mempools, langsameren Blöcken für Miner, die “Spam”-Tx einbauen, und letztlich zu Zentralisierung, da kleine Miner das Risiko meiden und große Pools dominieren.
Meine ursprüngliche Schlussfolgerung basiert also nicht auf einem Irrtum, sondern auf diesem Mechanismus – es geht um praktische Delays durch fehlende Tx, nicht um Block-Filtering. Wenn du Quellen hast, die das widerlegen (z. B. dass Compact Blocks immer delay-frei sind), teile sie gerne, und ich schaue mir das an!
das Zeitalter der KI hat begonnen. ich hoffe, dass all diese Leute sich auch von der KI behandeln lassen. Wozu noch zum Arzt gehen. Einfach KI fragen und die Pillen schmeißen, die vorgeschlagen werden.
das wäre nur der Fall, wenn die überwältigende Mehrheit der Nodes, also deutlich über 95% der nodes im gesamten Bitcoin-Netzwerk filtern würde. Passiert das?Nein. Also gibts auch keine Verzögerung. Und selbst wenn es über 95% wären, dann würde es sich 1. nur um Millisekunden handeln und 2. so oft kommt es auch nicht vor, dass 2 Blöcke gleichzeitig gemined werden.
Ihr spricht hier über einen Fall, der zur Zeit nicht existiert und wenn er was ich nicht glaube irgendwann existieren wird, dann wird es auch nur die Blöcke betreffen, die gleichzeitig gefunden werden. Also eine Ausnahme eienr Ausnahme.
So und ich bin out. Ihr könnt ja gerne weiter mit der KI diskutieren, meine Zeit ist mir dafür zu schade. Und für diejenigen die die Likes verteilen, ihr seit Mitläufer. Ein paar Tips an euch: Lesen, verarbeiten, verstehen. Nicht andern hinterherlaufen weil es sich irgendwie cool anhört. Erinnert mich an die ganzen religiösen Fanatiker, ohne jetzt einen von euch damit meinen zu wollen. Sorry versteht mich nicht falsch. Wozu gibts eigentlich noch Foren?
Verstehe nicht woher du die Daten von 95% hast? Die Wahrscheinlichkeit, dass innerhalb einer Sekunde zwei Blöcke gefunden werden, liegt im Mittel bei rund acht Tagen; innerhalb von fünf Sekunden passiert das etwa alle zwei Tage. Schon kleine Verzögerungen bei der Blockverbreitung können daher entscheidend sein. Große Pools minimieren dieses Risiko, indem sie ihre Blöcke direkt an andere große Pools weiterleiten. Findet jedoch ein unabhängiger oder kleiner Pool den nächsten Block, bestimmt er den gültigen Vorgänger.
Eine stärkere Dezentralisierung des Minings würde den Nodes mehr Mitspracherecht über die Auswahl der Transaktionen geben. Stratum V2 ist eine wichtige Entwicklung in diese Richtung. Node-Filter würden in einem dezentraleren Mining-Umfeld zusätzlich bewirken, dass Miner sich stärker am Willen der Nodes orientieren. Aus eigenem Interesse, um das Risiko von verwaisten Blöcken zu senken.
Ich glaube viele, gehen bereits davon aus, dass Mining dauerhaft zentralisiert bleibt. Weswegen man das Ignoriert.
Ihr wisst, worauf ich hinauswill: Die Blockvorlagen-Erstellung (Block Template Creation) ist zentralisiert, da der Pool für alle entscheidet, welche Transaktionen aufgenommen werden.
Ich halte meine Argumentation für nachvollziehbar und sehe die Kritik an der Änderung als berechtigt. Wenn ihr das anders einschätzt, ist das in Ordnung, aber das Herabspielen meiner Sichtweise, als gäbe es nur eine „richtige“ Meinung, empfinde ich als unfair. (und viele Ebenfalls)
Jede Änderung am Bitcoin ist mit Risiken verbunden. Aus meiner Sicht bringt die Aufhebung der Limitierung keinen wirklichen Vorteil für den monetären Nutzen von Bitcoin. Deshalb sehe ich diese Änderung kritisch.
Aber auf Protokoll Ebene gab es noch nie eine Limitierung…nur das hilft dir nicht weiter , denn du willst es ja nicht verstehen, oder kannst es nicht verstehen…
Wunderbare Wortkombination.
