Dieses Begleitthema zu https://www.blocktrainer.de/blog/bitcoin-core-hebt-op-return-limit-nach-kontroverser-debatte-auf wurde automatisch erstellt. Antworten auf dieses Thema werden unter dem Beitrag auf der Webseite eingeblendet.
Dieses Begleitthema zu https://www.blocktrainer.de/blog/bitcoin-core-hebt-op-return-limit-nach-kontroverser-debatte-auf wurde automatisch erstellt. Antworten auf dieses Thema werden unter dem Beitrag auf der Webseite eingeblendet.
3 „Gefällt mir“
Das heißt also, dass man selbst entscheiden kann, ob man zusätzliche Daten speichern möchte, die nicht zwingend erforderlich sind, um den gültigen Block mit den Transaktionen aufzunehmen? Dann habe ich damit kein Problem.
Ein neues Tutorial wie man Bitcoin Knots betreibt und wie man datacarrieresize und andere Variables „richtig“ (wenn man Bitcoin weiterhin als Geld benutzen will und nicht als Spam Datenbank) einsetzt wäre schon erwünschenswert.
Ich bin erst seit Oktober 2024 bei Bitcoin dabei und - in den Augen der Bitcoin-Core-Developer - sicher „technisch ungebildet“. Ich denke, ich habe jedoch relativ schnell viel über Bitcoin gelernt. Als Reaktion auf die etwas abgehobene Meinung der Bitcoin-Core-Developer betreibe ich seit letztem Freitag einen Node - mit „Bitcoin Knots“, das eine grössere Freiheit bei den Einstellungen zulässt. Es gibt dazu übrigens gute Youtube-Videos! Herzliche Grüsse aus der Schweiz.
1 „Gefällt mir“
Das von einem einzigen Entwickler, der bei einem Hack kürzlich mehrere Millionen USD in Bitcoin verloren hat, als Nebenprojekt betrieben wird…
Ich hoffe du nutzt Knots nicht im Zusammenhang mit Geld :D
5 „Gefällt mir“
In ein paar Jahren/Jahrzehnten wird es um deutlich wichtigere und kontroversere Änderungen gehen. Bitcoin ist dezentral und jeder ist herzlich eingeladen seine Ideen vorzustellen und umzusetzen.
Jahre lang die anderen machen lassen, dann meckern, aber selber nichts machen ist nicht zielführend.
Alles ist gut für Bitcoin. Solche Debatten regen das Immunsystem von Bitcoin an und inspirieren hoffentlich weitere Programmierer.
5 „Gefällt mir“
Der Ökonomische Faktor wird das schon regeln
3 „Gefällt mir“
Der Entwickler der Bitcoin Knots „entwickelt“ hat - dem wurden mehrere Mio USD in BTC durch einen Hack gestohlen?
Wer ist das? Wo kann man mehr darüber nachlesen?
Dashjr also warned that users of the Bitcoin Knots wallet and should double-check their installation because it could be using his compromised PGP keys.
Wie kann das passieren?
Das man diese PGP keys kompromitiert?
Ist ein einziger Entwickler ein Problem? Meiner Meinung nach nicht! Wenn er es besser macht als die anderen, wird er schon die allenfalls nötigen Partner finden. Einen Zusammenhang des Themas in eurem Artikel mit dem erwähnten (zweifelhaften) Hack kann ich auch nicht erkennen. Schau’mer mal, wie diese Geschichte weitergeht. Der Anteil von Bitcoin Knots bei den Nodes steigt jedenfalls.
1 „Gefällt mir“
Wenn ich das richtig verstanden habe, kann ich in meiner Node damit nur konfigurieren ob ich so eine nicht verarbeitete Transaktionen annehme und im Netzwerk weiterverteilen möchte. Spätestens wenn die durch einen Miner in einen gültigen Block eingebunden ist, lade ich mir die Daten unweigerlich runter. Richtig?
1 „Gefällt mir“
das ist schon vor jahren passiert.
indem man ihn stiehlt. die Kryptographie ist sicher, aber wenn du dir Viren aufn pc holst, kann alles passieren. da ist nix mehr sicher. deswegen hat er auch öffentlich gemacht, dass er jetzt einen neuen Private Key nutzt und die Leute deswegen den zugehörigen public key nutzen sollen und nicht den alten public key.
Das stimmt. Das war allerdings vorher auch schon so. Man erinnere sich an die Inscription mit 3.9 MB von Anfang 2023. Die mussten auch alle Nodes annehmen, als sie von einem Miner in einen Block integriert wurde, obwohl sie die Standardwerte gesprengt hat wie wohl noch nie eine Transaktion vorher.
Die Speicherung über OP_RETURN ist übrigens „standardmäßig“ an das 100 kB-Limit pro Transaktion gebunden. Auch hier könnte ein Miner, der die Standardwerte ignoriert, immerhin eine fast 1 MB große Daten-Transaktion minen. Auch das war schon bisher möglich.
1 „Gefällt mir“
Auch mit Knots kann sowas wie Bitcoin Stamps nicht verhindert werden. Also die Speicherung von Daten in dem Feld für Adressen bzw. öffentliche Schlüssel. Und wie Gloria Zhao erklärt ist diese Speicherung viel schädlicher als die über OP_RETURN, weil diese Daten auch von „pruned“ Nodes nicht gelöscht werden können. Nodes halten diese Daten für echte öffentliche Schlüssel, es gibt keine Möglichkeit das wirklich glasklar zu unterscheiden.
1 „Gefällt mir“
Insgesamt gibt mir diese Debatte verschiedene Einsichten.
Einerseits kann ich die Absicht nachvollziehen durch das eliminieren des OP_Return Limits den „Spam“ in den „weniger schädlichen“ Bereich zu ziehen (inwiefern kann dieser eigentlich gepruned werden?). Andererseits ist es ein zusätzlicher Incentive für nicht-monetäre Informationen, da die andere Option ja nicht wegfällt und korrekterweise auch nie wegfallen wird.
Generell frage ich mich dennoch, warum sich so viele Bitcoiner sich beschweren, da es sich doch um Opensource Software handelt, welche abwärtskompatibel ist.
Aus meiner Sicht kann man also
a) entweder eine ältere Version von Bitcoin Core weiterlaufen lassen → mit dem Risiko, dass auch sicherheitstechnische Aspekte nicht mehr gefixt werden
b) einen anderen Client wie Knots, Libbitcoin nutzen → Risiko der wenigen Entwickler (wobei der Großteil bei Knots auf Bitcoin Core basiert, soweit mir bekannt ist)
c) einen neuen Client entwickeln (klar das ist sehr aufwändig - wobei hier sicher ein Großteil von bereits bestehenden Clients wiederverwendet werden kann - siehe Knots) → insbesondere für größere Player mit dem Fokus auf Bitcoin als Geld aber durchaus möglich
d) es ist eigentlich unerheblich und man kann bei Bitcoin Core bleiben, da es diese Parametrisierung auch vorher schon gab (wenn auch nicht als Standard → Risiko der schlechteren Verbreitung durch abweichende Mempool-Policy. Diese gilt aber eigentlich nur für das aufgehobene Limit)
Falls ich hier irgendwo falsch liege, dann korrigiert mich bitte - bin halt kein Entwickler ;)
Eine Einordnung von den technisch sehr versierten Bitcoinern hier (@sutterseba zum Beispiel ;) ) würde mich dazu sehr interessieren (inklusive persönlicher Meinung, welche mir auch im Artikel fehlt).
Es wird auch interessant sein, wie sich die Verbreitung der neuen Bitcoin Core Version entwickelt - dies wird die Akzeptanz der Änderung aufzeigen.
Die gängige Meinung:
Es ist ok das man das OP return Limit ändert, weil sonst die Spammer andere Methoden verwenden und unser UTXO Set aufblähen und das wäre schädlich. Und wir sollten nicht versuchen bestimmte Transaktionen zu zensieren, weil Zensur ist ja böse, und außerdem kann der Spammer ja immer den Miner direkt bezahlen und deshalb können wir den Spam sowieso nie aufhalten, also lieber gleich aufgeben.
Die Richtigstellung:
Wir, die Nodes, bestimmen was Bitcoin ist und was es nicht ist. Das hat nichts mit Zensur zu tun. Spam ist schädlich und sollte nicht verharmlost werden. Und es gibt hier auch nichts klein beizugeben. Wenn wir keinen Spam wollen, dann können wir das auch verhindern. Und zwar folgendermaßen:
Wenn ein großer Prozentsatz der Nodes Spam filtert und die Tx die Spam enthalten nicht weiterleitet, dann bedeutet dass auch, dass neue Blöcke die gefunden werden und Spam enthalten von diesen Nodes mehr Zeit brauchen um verifiziert zu werden. Damit werden diese Blöcke dann langsamer im Netz verteilt als normale Blöcke.
Die Miner haben nun ein Problem, wenn nämlich ihr Spam Block sich nur langsam verbreitet, so kann jemand anderes mit einem normalen Block schneller sein, und der Spam-Miner hat das nachsehen. Millisekunden entscheiden über einen großen wirtschaftlichen Vor oder Nachteil.
Wir wir Nodes also den Spam blockieren, so haben auch die Miner überhaupt kein Interesse mehr Spam Blöcke zu bauen, weil sie das Geld kostet. Und dann werden sie auch keine extra bezahlten Spam Transaktionen mehr annehmen. Es reicht geschätzt bereits ein Anteil von 40% der Nodes. Aktuell wird Knots bereits auf 11% geschätzt. Tendenz steigend.
Daher macht es Sinn im Kampf gegen Spam nicht klein bei zu geben, sondern eine Node laufen zu lassen die Spam blockiert. Z.b. eben knots.
Wir entscheiden was Bitcoin ist!
Lasst euch von niemandem einen Bären aufbinden, auch nicht von Core Devs.
Die hab ich im Artikel bewusst rausgelassen, weil der ohnehin schon recht lang war.
Falls du sie noch nicht gehört hast, kann ich auch die Podcastfolge dazu empfehlen, die ich mit Murch aufgezeichnet habe. Die ist auch im Artikel verlinkt.
Meine Meinung dazu ist, dass das Thema deutlich zu aufgebauscht ist, für das was es eigentlich ist. In der Debatte sind viele große Egos, teilweise viel Meinung und wenig Ahnung und nur wenig berechtigte Kritik.
Wie auch Jamseon Lopp sagte: „Auf zu wichtigeren Dingen“.
3 „Gefällt mir“
Würde mein Node wirklich die Transaktion über einen geminten Block nachträglich downloaden oder würde er das rausfiltern wenn die Transaktiongröße zu groß ist und nur den Blockheader mit gültigem Hash und den restlichen Transaktionen beziehen?
Danke dir, das werde ich mir mal anhören 
Ist auch mein Eindruck, aber bin eben auch zu weit weg, um es abschließend zu beurteilen, ohne der Gefahr gefährlichen Halbwissens zu unterliegen…