ich habe bereits einige Beiträge zum Thema OP_RETURN gelesen, aber in meinem Kopf besteht aktuell ein Widerspruch, den ich gerne klären würde.
Roman hat in früheren Streams sinngemäß erklärt:
Der OP_RETURN-Längenwert sei keine Konsensregel, sondern eher eine Art „lokale Client-Einstellung“.
Es sei vergleichbar mit verschiedenen Browsern im Internet – jeder interpretiert HTML etwas anders, aber das Internet bleibt das gleiche.
Soweit, so gut. Doch wenn ich nun eine Node betreibe, die z. B. einen OP_RETURN-Wert nicht akzeptiert, weil er zu lang ist – dann würde meine Node doch den gesamten Block ablehnen, der solch einen Output enthält, oder? Und damit lehne ich auch automatisch alle nachfolgenden Blöcke ab, da sie auf einem „ungültigen“ basieren – aus meiner Sicht.
Dann entsteht doch de facto ein Soft Fork? Zumindest für meine Node – sie folgt einer anderen Chain. Und wenn andere Nodes denselben Client mit denselben Einschränkungen nutzen, spalten wir uns doch potenziell ab?
Meine zentrale Verwirrung ist: Was bedeutet es konkret, wenn etwas „keine Konsensregel“ ist?
Wenn meine Node einen Block ablehnt – sei es wegen OP_RETURN oder aus einem anderen Grund – ist das doch ein harter Cut. Entweder akzeptiert meine Node den Block oder nicht. Wo genau soll da „kein Konsens“ greifen, wenn es technisch doch binär ist?
Auch der Vergleich mit Browsern hinkt für mich: Im Web kann ich Seiten unterschiedlich anzeigen, aber im Bitcoin-Netzwerk muss ein Block entweder angenommen oder abgelehnt werden – es gibt keine Zwischenstufen.
Seht ihr meinen Denkfehler? Oder übersehe ich etwas Grundlegendes?
Ist der OP_RETURN „lang“, so entspricht das immer noch den Konsenregeln von Bitcoin und auch Bitcoin Core hat Blöcke die „grosse“ OP_RETURN Daten hatten immer akzeptiert.
Core hat einzig Transaktionen die lange OP_RETURN Daten hatten nicht an andere Nodes weitergeleitet (Gossip Protokoll).
So hatten es Transaktionen die viel im OP_RETURN hatten schwirig zu einem Miner zu gelangen. Haben sie es trotzdem geschafft (weil z.B. direkt an Miner gesendet oder über Nodes die die Limite ignorierten) kamen die Transaktionen trotzdem in Block.
Nun wurde die Limite aufgehoben was einige zum „jetzt gibt es mehr Spam auf Bitcoin“ schreien bringt, andere erkennen, dass es eh nichts verändert ausser, dass es vielleicht den Betrieb von Core Nodes etwas effizienter macht da diese nun bei einem gefunden Block mit viel OP_RETURN nicht immer noch erst die Transaktionen die sie nicht hatten verarbeiten müssen.
Meiner Meinung nach ist die ganze Geschichte super viel Aufregung um fast nichts.
Nein, zum Zeitpunkt des Blockfundes hast du diese Transaktion nicht im lokalen Client (deinen Mempool), aber musst sie zur Verifikation des Blockes nachträglich von anderen Clients nachladen. Heißt, schlussendlich hast die von dir abgelehnte Transaktion dennoch im gespeicherten Block vorliegen.
Danke für die Antwort – das hat mir geholfen, das Thema besser einzuordnen.
Ich hätte aber noch eine Folgefrage zur möglichen Auswirkung, wenn bestimmte Transaktionen – z. B. mit langem OP_RETURN – zwar konsenskonform sind, aber von vielen Nodes nicht weitergeleitet werden (also nicht im Mempool landen).
In so einem Fall könnte doch ein Miner, der die Transaktion direkt kennt, sie in einen Block aufnehmen – aber viele andere Nodes kennen sie nicht und müssen sie beim Empfang des Blocks erst nachladen und verifizieren.
Könnte es dann nicht passieren, dass dieser Block langsamer propagiert wird – und in der Zwischenzeit ein anderer Miner einen konkurrierenden Block findet, der schneller im Netzwerk zirkuliert, weil er nur allgemein bekannte Transaktionen enthält?
→ Der ursprüngliche Block würde dann nicht aufgenommen, obwohl er eigentlich gültig war.
Und in diesem Zusammenhang noch ein weiterführender Gedanke:
Ist es realistisch, dass Unternehmen oder Projekte, die bestimmte Transaktionen (z. B. OP_RETURN mit viel Daten) zuverlässig in die Blockchain bringen wollen, gezielt Infrastruktur aufbauen, um ihre Transaktionen direkt an große Miningpools weiterzuleiten?
Also z. B. durch:
Eigene gut vernetzte Full Nodes mit direkten Peers zu Pools
Mehrfache Verteilung über API-Schnittstellen
Nutzung von Miningpool-nahen Broadcast-Diensten
Direkte Connections oder Absprachen mit Pools
→ Sprich: Auch wenn es technisch keine „Zensur“ im Protokoll gibt, hängt der Erfolg einer Transaktion in der Praxis dann stark von der Netzwerkinfrastruktur und Nähe zu Miningpools ab?