Darüber habe ich auch schon nachgedacht. Stellen Inscriptions nicht irgendwann sogar einen Anreiz für Miner da weil dadurch der mempool geflutet wird und die Preise hoch getrieben werden. Natürlich nicht einzelne Transaktionen aber in einer kordinierten Aktion?
95% der Coinjoins werden nicht gefiltert. Nur eine einziger Transaktionstyp von Samurai wird gefiltert und dieser Transaktionstyp benötigt diese Methode nicht mal.
1 „Gefällt mir“
@sun Okay, da würde ich mitgehen. Man müsste bei dem Vorgehen allerdings darauf achten, dass man nicht noch größeren Blödsinn wie z.B. STAMPS heraufbeschwört.
@sypher Auf jeden Fall, STAMPS sind regelrecht bösartig.
Kannst du schon jetzt filtern mit:
permitbaremultisig=0
Genauso kannst du ohne manuelles Patchen die meisten BRC-20 tx rausfiltern mit:
dustrelayfee=0.00003001
Hintergrund: die meisten BRC-20 tx bewegen nur 546 sats, also knapp über dem Dust-Limit. Das hebt das Limit einfach minimal an … und tschüss.
1 „Gefällt mir“
Das ist sehr hilfreich. Ich betreibe meine Full-Node auch schon mit Luke Dashjrs Ordisrespector-Patch seit das Ordinals-Thema aufkam. Wir dürfen uns allerdings nichts vormachen, das bremst die Ordinals in keiner Weise, solange kein überwältigender Konsens dagegen besteht.
1 „Gefällt mir“
Jopp, ist eher eine Sache von Prinzipien.
Wie gesagt, wäre echt hilfreich da eine vernünftige Option gestellt zu bekommen, anstatt dass sich Plebs selbst was zurechtbasteln müssen. Dann würde das auch mehr genutzt werden und ein entsprechendes „Damoklesschwert“ über Ordinalsprojekten schweben.
1 „Gefällt mir“
Luke hat gerade geschrieben, dass er nicht diesen CVE geschrieben hat.
Quelle:
https://x.com/lukedashjr/status/1733919832234438916?s=46
1 „Gefällt mir“
Bitcoin ist eine Reaktion auf (die Lösung für) das vermeintliche „Problem“.
Die Idee Spam prohibitiv teuer zu machen, findet sich schon in Hashcash und war der Vorläufer von Proof of Work wie in Bitcoin.
Die ganze Aufregung lässt sich darauf reduzieren, dass manche Menschen bereit sind, viel Geld für komische Dinge auszugeben.
Abgesehen davon lässt sich das „Problem“ gar nicht lösen. Hashes oder auch Public Keys sind erst als solche erkennbar, wenn sie referenziert werden. Bis das nicht passiert, sind sie Spam.
Mic Drop. Diskussion beendet.
5 „Gefällt mir“
Die Idee Spam prohibitiv teuer zu machen, findet sich schon in Hashcash und war der Vorläufer von Proof of Work wie in Bitcoin.
Hier geht es nicht um Spamprävention im Sinne von PoW, sondern darum, dass arbiträre Daten in Transaktionen per Exploit untergebracht werden, was den Spam unnötig zu einem sich selbst antreibenden System macht. Jetzt hast du ein Kasino auf der Blockchain und Kasinos gehen nicht pleite, auch wenn die meisten ihr Geld dort verlieren.
Die ganze Aufregung lässt sich darauf reduzieren, dass manche Menschen bereit sind, viel Geld für komische Dinge auszugeben.
Falsch, es lässt sich darauf reduzieren, dass Bitcoin Core es verpennt hat / sich weigert, die beiden Optionen datacarrier und datacarriersize konsequent auch auf Ordinal tx anzuwenden. Und das Resultat ist spürbar.
Abgesehen davon lässt sich das „Problem“ gar nicht lösen.
Technisch und historisch ignorante Aussage. Das Problem gab es schon lange und wurde schon zufriedenstellend per mempool policies gelöst, bevor man den Kopf in den Sand gesteckt hat. Lies dir genau durch, was ich in diesem Thread beschrieben und referenziert habe.
Hashes oder auch Public Keys sind erst als solche erkennbar, wenn sie referenziert werden. Bis das nicht passiert, sind sie Spam.
Am Thema vorbei geredet.
Mic Drop. Diskussion beendet.
wtf?
Ein vollständig dezentrales Datenbanksystem, das das Problem des Doublespending löst, thermodynamisch abgesichert ist und im Durchschnitt alle 10 Minuten nur 1,5 MB Speicher zulässt, ist natürlich kostspielig.
Ich erkenne bedeutende Vorteile und bin erfreut darüber, dass die Ordinals die Transaktionen verteuert und den Mempool füllt. Miner verdienen mehr durch Transaktionsgebühren, was zu einer Steigerung der Hashrate führt. Außerdem können sie die höheren Gebühren gut gebrauchen, da das Halving bevorsteht und sie früher oder später sowieso mehr verlangen müssen, um rentabel zu bleiben.
Zusätzlich freue ich mich darüber, dass dies dem Lightning-Netzwerk eine viel höhere Relevanz verleiht.
Wenn wir beginnen, an den Regeln des Netzwerks herumzuschrauben, verdienen die Miner offensichtlich weniger. Zwar sind die On-Chain-Transaktionen für uns dann etwas günstiger, aber das Lightning-Netzwerk verliert wieder an Relevanz im Vergleich zur aktuellen Situation.
1 „Gefällt mir“
Man wird immer arbiträre Daten in die Blockchain bekommen. Das ist der Punkt.
Schlüssel und Hashes sind nicht von arbiträren Daten unterscheidbar, oder siehst du das anders?
Die Idee bei Hashcash war, durch Proof of Work die Kosten zu erhöhen und so Spam zu verhindern. Ob die Spamprävention nun durch Transaktionskosten erfolgt, spielt keine Rolle. Das Prinzip ist das gleiche. Deshalb schreibe ich:
6 „Gefällt mir“
Man wird immer arbiträre Daten in die Blockchain bekommen. Das ist der Punkt.
Auf das Argument bin ich schon in meinem ersten Post im Thread eingegangen. Will nicht mein eigenes Zeug copy-pasten. Stichwort: Anreize.
Schlüssel und Hashes sind nicht von arbiträren Daten unterscheidbar, oder siehst du das anders?
Ob die Daten arbiträr sind hängt davon ab, ob sie Relevanz für die tx im Sinne der Protokollregeln haben. Schlüssel als pubkey: nicht arbiträr. Schlüssel in einer Inscription geschmuggelt: arbiträr.
Die Idee bei Hashcash war, durch Proof of Work die Kosten zu erhöhen und so Spam zu verhindern. Ob die Spamprävention nun durch Transaktionskosten erfolgt, spielt keine Rolle. Das Prinzip ist das gleiche.
Ich will nicht abstreiten, dass kleine Blöcke + fees das Problem langfristig lösen können. Mein Problem ist, dass man sich auf dem Weg dahin schön dumm anstellt anstatt Schadensbegrenzung zu betreiben. Beispiel: die Sache nicht mal beim Namen nennen zu können: Es ist ein technischer Exploit.
1 „Gefällt mir“
Der Artikel gibt die Situation leider meiner Meinung nach völlig falsch wieder. Diese Meldung bezieht sich darauf, dass Bitcoin Core eine Option datacarriersize hat, die beschränkt, wie groß OP_RETURNs sein dürfen, die weitergeleitet werden (Es betrifft also nur Weiterleiten und Minen, nicht die generelle Akzeptanz solcher Transaktionen).
Diese Option ist dokumentiert mit
Maximum size of data in data carrier transactions we relay and mine
Es geht hier nicht um das Netzwerk, sondern um Core selbst. Laut Luke’s CVE sollte diese Option, so wie es dokumentiert ist, alle „Data carrier transactions“ limitieren. Aktuell beachtet sie aber nur OP_RETURN, und sonst nichts. Das kann als Bug oder Sicherheitslücke interpretiert werden, da Ordinals ja definitiv nur dazu da sind, Daten zu übertragen. Sicherheitslücke deshalb, weil eine Limitierung, die bewusst eingebaut wurde, umgangen werden kann.
Es werden also nicht Inscriptions selbst als Sicherheitslücke gemeldet, sondern auf ein existierendes, wenn auch kleines Problem in der Dokumentation (oder Umsetzung dieser) aufmerksam gemacht, auch wenn das natürlich mit seinem Vorgehen gegen Inscriptions zusammenhängt.
2 „Gefällt mir“
Lol
Ok, das ist mir recht Suspekt. Weil es dürfte ja ziehmlich offensichtlich sein wie die Bitcoin Community darauf reagiert. Nämlich das dies ein Versuch ist mittels Druck eine Konsensänderung zu erzwingen, also ein Angriff auf Bitcoin.
Und die Reaktion darauf ist dann das alle die auch nur darüber nachdenken die Ordinals zu verbieten logischerweise im Bunde mit dem Verräter und Angreifer sind und aus dem Maxi Zirkel geschmissen werden (auf Twitter geblockt). Natürlich ist dann die ganze Diskussion ob das jetzt Spam und Ok ist für die nächsten 10 Jahre geblockt, weil will sich ja keiner als big-blocker anti-wizzard outen
Also entweder war jemand der gegen Ordinals ist so komplett verblödet und hat sich selbst und seinen Freunden ins Bein geschossen…
… oder …
… das waren die Anderen, weil die genau wussten was dann passiert.
Nein, eben keine Konsensänderung. Es geht um eine Einstellung, die es seit 2014 gibt, nicht um irgendwas neues von Luke-jr, die Miner und Nodebetreiber eigentlich schon immer selber treffen sollten.
2 „Gefällt mir“
Ok, das ist mir recht Suspekt. Weil es dürfte ja ziehmlich offensichtlich sein wie die Bitcoin Community darauf reagiert. Nämlich das dies ein Versuch ist mittels Druck eine Konsensänderung zu erzwingen, also ein Angriff auf Bitcoin.
Du hast technisch falsch verstanden, was hier passiert, bzw. was gefordert wird und interpretierst das jetzt in eine seltsame verschwörerische Richtung. Lies dir bitte an, was der Unterschied zwischen mempool policies und Konsens ist.
Generell empfehle für den Einstieg in das Thema den Artikel: https://habla.news/jb55/1701876273423
3 „Gefällt mir“
Ja danke. Dein Vorposter hat mich bereits korrigiert. Ich gebe euch recht
1 „Gefällt mir“