Ich denke, wir haben verschiedene Definitionen von vollgestopft
Solang jeden Tag mehrfach halbleere Blöcke kommen, weil nicht genug Transaktionen im Mempool sind, würde ich bei weitem nicht davon sprechen, dass etwas vollgestopft ist.
Quatsch.
Die 4MB wurden so gewählt, weil sie ok sind, das darf man schon ausnutzen.
Wir sind gerade am Punkt, an dem eine 1TB Festplatte nicht mehr reicht. Die nächte Größe sind 2 TB, bis diese nicht mehr reicht haben wir noch 4 Jahre, selbst wenn jedes Byte vollgestopft werden würde.
Ob wir jetzt in 4 Jahren eine größere Festplatte brauchen oder in 6 spielt wohl keine so große Rolle, in der Zeit haben Bitcoiner vielleicht ein 5x gemacht und Festplatten sind saugünstig geworden.
Ich finde es echt komisch, dass die einen sagen, wir hätten zu wenig Transaktionen und die Miner sterben aus und die anderen sagen, wir hätten zu viele Transaktionen und die Nodes sterben aus.
Aber nicht mehr lange. Und wie… Ich habe selbst schon Erfahrung gemacht mit dem Betreiben einer Bitcoin Node + LND auf begrenzter Hardware. (10 Jahre alter Laptop mit 8GiB RAM) Und ab Beginn des Inscription Hypes 2023 lief das Ding schrecklich langsam.
Grund dafuer ist vermutlich auch dass das UTXO Set so aufgeblaeht wurde, dass es nicht mehr in den RAM passt und somit die Validierung von Transaktionen dauernde I/O-Zugriffe benoetigt. Stell aufjedenfall sicher dass das chainstateVerzeichnis zumindest auf einer SSD ist.
Das stimmt. Dann waere die Wachstumsrate der Chain schon viel frueher angestiegen.
Scheinbar. Du betrachtest wohl die vBytes. Ich betrachte die Bytes, denn die sind letztendlich das was meine Platte auffuellt.
Die halbleeren Bloecke haben wir nur dank Mining-Pools die nicht Transaktionen unter 1sat/vB aufnehmen. Im 0.1sat/vB Mempool liegt jede Menge an Transaktionen herum. (Groesstenteils leider Spam)
2017 war es noch eine heftige Debatte zwischen 1MB vs. 2MB. Und jetzt sind 4MB ploetzlich okay?
Bedenke dass sich auch ein bisschen mehr Speicherverbrauch ueber die Zeit stark summiert. Und Plattenspeicher ist nicht das einzige Problem. Die Chain muss ja schliesslich beim Aufsetzen einer neuen Node komplett heruntergeladen werden. Je groesser die Chain, desto laenger dauert das.
woran hast du das ausgemacht, dass es langsam lief?der Initiale download oder kam deine node mit dem Prozessieren der Blöcke nicht zurecht. Also bei mir läuft alles aufm Raspi, wo zusätzlich ein mempool explorer läuft (der ist sogar rechenintensiver als die node) und ein paar weitere Programme laufen. Alles läuft tiptop.
das UTXO-Set ist nicht durchgehend im RAM geladen, sondern nur ein Teil. Der Rest leigt auf der SSD. Standardmäßig ist im RAM vielelicht 1 GB geladen. Je nachdem wieviel man hat, kann man das sogar höher schrauben und auf 4-5 GB gehen. Also da ist noch sehr viel Luft nach oben und das bei nen Raspberry Pi. Mal hier nicht den teufel an die Wand.
wie kommst du darauf dass es größtenteils Spam ist?Ich verschicke auch Transaktionen unter 1 sat/vB und das ohne Bilder.
ne 2017 war die Debatte die Blockgröße je bestimmte Zeit zu verdoppeln (nach dem Motto wie bei Moores Law aber mit Festplatten). Dieser Eingriff war viel schwerwiegender. Wir haben immernoch 1 MB Blöcke und das bleibt auch so vorerst. Lediglich die Witness-Daten erhöhen die Blöckgröße minimal, aber auch das nur bei den nodes, die Segwit und lightning nutzen möchten. Alle anderen nodes haben 1 MB Blöcke. Also bitte auch hier nicht den teufel an die Wand malen. Bitcoin ist immernoch abwärtskompatibel. Kannst du dir keine Festplatte leisten, dann lasse eine node laufen ohne segwit, wobei auch das lächerlich ist. Ne 2 TB Festplatte reicht für die nächsten Jahre aus.
Wo liegt denn hier das Problem?Mittlerweile hat so gut wie jeder mindestens eine 100 MBit-Leitung. So lange dauert das gar nicht. Was lange dauert ist die Verifizierung der Block-Header und auch dafür gibt es Lösungen. Muss man sich halt mal etwas schlau machen ;-)
Also ich Merk schon es sorgt auf jedenfall für Spaltung.leider bin ich jetzt aber kein Stück weiter, generell kann ich ja mit mein Knots gewisse Dinge einstellen die dafür sorgen das ich kein Spam verteile. Also warum dann genau dieser fork? Damit es nur Transaktion sind und keine lustigen Bildchen?
BIP-110 wird kommen und sich durchsetzen. In den USA sieht man die Entwicklung von Core v30 deutlich kritischer als hierzulande. Ob du jetzt aufspringst oder später, spielt keine große Rolle. Bei mir ist es jedenfalls bereits aktiv.
Mit Knots ohne BIP-110 filterst du den Spam nur aus deinem Mempool und leitest den auch nicht weiter. Jedoch akzeptierst du trotzdem Bloecke die Spam enthalten. BIP-110 waere aber ein Soft Fork der Bloecke die Spam enthalten ablehnt. (eine Aenderung im Konsensus)
Urspruenglich hatte ich eine HDD mit ZFS und das war komplett unbrauchbar. Das validieren eines einzigen Blocks dauerte saemtliche Minuten. Und parallel Lightning Zahlungen zu taetigen war ein Krampf. Mit einer SATA SSD ohne DRAM-Cache war es dann etwas besser: Ungefaehr ein Block pro Minute. Prozessor war uebrigens: Intel Celeron N2940 (4 cores)
Mittelerweile hab ich orderntliche Server-Hardware:
AMD Ryzen 5 9600
32 GiB ECC RAM
PCIe 4.0 NVME SSDs mit DRAM Cache
Da laeuft das super.
Standardmaessig sind es 450 MB. Natuerlich schraub ich den dbcache Wert beim Aufsetzen einer Node hoch. Aber selbst meine aktuellen 32 GiB reichen nicht aus um das ganze UTXO-Set zu halten.
Aber beim UTXO-Set male ich auch keinen Teufel an die Wand, denn es wird eh schon an einer Loesung gearbeitet: Utreexo
Nur aktuell ist das eben noch nicht in den relevanten Node-Implementierungen eingebaut.
Schau auf mempool.space und stell Mempool Goggles auf “Data”.
In dem Beispiel 100% Spam zwischen 0.13-0.14 sat/vB.
Das stimmt nicht. Jede Version von Bitcoin Core/Knots seit 0.13.1 speichert auch Witness-Daten.
Ein alte Version voller Sicherheitsluecken und ohne Lightning Unterstuetzung
Du vielleicht aber Leute in Syrien oder Afghanistan haben mit einem Bruchteil davon zu kaempfen. Und selbst in Deutschland hat sicher nicht jeder 100 MBit/s.
Bitcoin ist keine Datenablage Software wie Google Drive oder sowas ähnliches.
Solche Daten (im Tor Browser öffnen) gehören einfach nicht in die Blockchain rein und die Tatsache, dass wir früher (vor 10 Jahren) das noch wussten und jetzt nicht mehr ist ein Grund wieso Luke Dashj ein bisschen Recht hat. Viele Bitcoin OG haben einfach ein bisschen den Pfaden verloren. Bitcoin ist Geld! Es benötigt keine weiteren Funktionalitäten! Weitere Funktionalitäten werden dem Bitcoin Geld erst dann zugefügt, wenn das Bitcoin als Geld scheitern könnte, wie z.B. Quantencomputer und so.
jo das erklärt einiges. HDDs kann man mittlerweile vergessen. SSDs müssen es bei der Synchronisierung schon sein.
ist ein alles oder nichts-Prinzip- Entweder die SSD kommt hinterher oder nicht. In deinem Fall hat die SSD einen 10x Puffer nach oben. Wenn die Blöcke alle 10 min kommen und du jeden Block nach 1 min durch hast, dann hast du ne funktionierende node, die zumindest eine 9-fach stärkere Belastung aushalten würde. Also alles gut.
wow okay, das ist schon überdimensioniert, aber wahrscheinlich laufen darauf noch andere Sachen als die Bitcoin-node oder?Sonst wäre das vieeeel zu krass wie gesagt, mein
Raspberry Pi5
8 GB Ram
ne alte 2TB SATA-SSD (also kein NVMe)
läuft bei mir reibungslos:
bitcoin-core
mempool-server
electrs-server
und noch ein paar kleine Programme
demnächst werde ich noch lightning draufpacken
genau. das reicht ja auch.
muss man ja auch nicht. Glaube das macht keiner von uns.
das sagt nur aus, dass Daten angehängt sind, aber nicht, dass es Spam ist. Oder bist du alle Daten dieses Blocks durchgegangen?und die Daten der meisten Daten-Transaktionen sind vergleichbar groß mit den normalen Transaktionen. Schau dir das mal genauer an. Die veröffentlichen da irgendein hash. Welchen use-case das für diese menschen hat, weißt du nicht. Mittlerweile gibt es sicherlich sehr viel Adoption beyond NFTs und dem ganzen Dreck. Nicht alles was unter Data aufgeführt ist, sind NFTs oder Bilder.
Lediglich die großen Inscriptions haben größere Datenpakete angehängt. Aber besser innerhalb von Inscriptions als in fakepubkeys, die dann erst Recht den UTXO-Set aufblähen. Und das kann man mit BIP444/110/Cat und wie sie alle heißen, dann sowieso nicht verhindern. Übrigens sind die Blöcke hier immernoch limitiert und wenn es Platz gibt, dann wird der Platz auch genutzt. Wofür auch immer. Dadurch bleibt es trotzdem bei 1MB/Block und die Blockchain wächst nicht schneller als sonst auch. Mit 1 MB/Block, sind wir für lange Zeit gut aufgestellt.Selbst zusammen mit den Witness-daten haben wir für lange zeit einen Puffer nach oben.
welche Sicherheitslücken?es gibt so viele nodes da draußen, die kein segwit haben wollen und die lassen die alte software laufen. entweder du möchtest witness-Daten oder du möchtest keine. wenn du lightning nutzen willst, solltest du minimal größere Blöcke akzeptieren. Das ist jetzt auch nicht die Welt und die Witness-Daten werden auch nicht immer ausgereizt. Also ist auch da noch für Jahrzehnte Pufer nach oben. So schnell kriegt man seine Festplatte nicht voll.
dass du dich mal nicht wunderst. Ich denke Deutschland hängt da global gesehen bei der Digitalisierung weit hinterher. Und wie gesagt, nicht die Internet-Leitung ist der limitierende Faktor, sondern die Validierung der Blöcke, also im Grunde genommen die Hardware der node.
gefällt keinem von uns. wenn man aber diese Pseudofilter mit Knots betreibt, dann werden die Leute auf fakepubkeys ausweichen und die kann man nicht filtern. Weil kein Filter wird erkennen können, ob es sich um einen public-key, hash oder angefügte Daten handelt. Das UTXO-Set wird dadurch dauerhaft aufgebläht, was viel schlimmer ist.
In meinen Augen sollte man sich mit 1-4 MB/Block arrangieren und wir alle können partizipieren, als Einheit und nicht gespalten. Daten sind nicht per se schlecht. Klar sind NFTs Müll, aber nicht alle Daten sind NFTs. Wenn man grundsätzlich Daten verbietet, dann inhibiert man die Adoption. Es gibt sicherlich viele use-cases, bei denen Daten gebraucht werden von denen sich die Knotzis gerade nicht vorstellen können wofür. Ich bin sicher, dass bessere 2nd-Layer darauf implementiert werden können. Aber sicher auch Dinge, die ich mir heute noch nicht vorstellen kann.
Es mit google Drive zu vergleichen ist schon extrem überspitzt. Man hat mittlerweile viel bessere Möglichkeiten seine Daten in der Cloud abzuspeichern und ist nicht auf 1-4 MB limitiert, was auch noch Unmengen an Geld kostet. Niemand wird die Blockchain als google Drive Ersatz verwenden, das ist lächerlich. Viel zu umständlich, seine Daten da wieder runterzuladen und zu verwalten.
diese Pseudofilter gab es schon vor Knots und die haben 99% der Zeit funktioniert.
LukeDashj hat vor ungefähr 2-3 Jahren damals ein Issue in den Bitcoin Core Github veröffentlicht, dass das zu UTXO bloat führen kann, wenn man diesen Inscription Bug nicht fixed, aber Gloria Zhao die damalige Bitcoin Maintainerin (oder Spam Queen) hat diesen Bug als Feature beschrieben.
das ist einfach nicht wahr und sorry, aber macht gar keinen Sinn. Inscriptions verursachen keinen UTXO-Bloat. Keine Ahnung wo du das her hast, aber Inscriptions erzeugen ja gerade eine gannz normalen Taproot-UTXO, wo die Daten im Witness liegen.UTXO-Bloat entsteht durch unspendabere Outputs wie fake-pubkeys oder extreme dust-outputs. Gerade Inscriptions haben gar nichts mit UTXO-Bloat am Hut.
das ist Polemik. nur weil sie keine Konsensregeln ändern möchte, bedeutet es nicht, dass sie eine Spam-Queen ist. Dieser Polemik bedienen sich ja gerade solche Leute wie Luke und das ist einfach nur unehrlich. Ich bin auch kein Spam-King, weil ich die Konsensregeln behalten möchte.
@silentpredator sorry hast Recht, hab das kurz verwechselt. Natürlich keine Inscriptions.
Hier ist dieser Closed Github Issue vom meinem vorherigen Kommentar:
Die Tatsache, dass dieser Issue damals nicht als Bug anerkannt wurde, und stattdessen als Feature ist eines der Hauptgründe, wenn nicht der Hauptgrund wieso wir heute so gespalten sind in der Bitcoin Community. Natürlich müssen wir alle auf einer Blockchain bleiben, weil das Hard Forken keinem was bringt. Beispiele dazu haben wir genug (Bitcoin Cash und BSV)
ja ich kenne die Debatte. Und auch wenn viele von uns keine Lust haben auf Daten in der Blockchain so wie Luke, sind sie nunmal nicht zu verhindern. Mit Luke’s „Fix“ werden Daten in der Chain nicht verhindert. Selbst wenn man alle möglichen Formen der Dateneinbettung verhindert, so bleibt am Ende immernoch die Möglichkeit, Daten über fake-pubkeys oder adress-hashes einzubetten. Und genau dieses Argument steht gegenüber Lukes Argument. Denn wenn die Leute Daten auf der Blockchain haben wollen, werden sie es spätestens auf diese Weise tun, was dann ganz besonders den UTXO-Set aufbläht und Bitcoin Schaden zufügt auf lange Sicht. Gerade Lukes Ansatz wird zu einem größeren UTXO-Bloat wie du es sagst führen. Es ist also kein Fix. Ich habe eher das Gefühl, dass Luke sich angegriffen fühlt und es persönlich nimmt, dass man seinen Vorschlag abgewiesen hat und jetzt scharrt er seine Jünger um sich, die größtenteils keine Ahnung vom Thema haben und polarisiert.
Daten bewusst zuzulassen, ist der beste Weg, sie „sauber“ ins Bitcoin-System einzuarbeiten, ohne das UTXO-Set auf lange Sicht aufzublähen. Und wie ich vorher schon meinte: Daten per se sind auch nicht schlecht. Man darf nicht alle Daten über einen Kamm scheren sind auch nur Daten
Ich erinnere mich noch an die Zeit vor 2023 als eine Node auf Raspi 4B 4GiB RAM + 750 GB HDD kein Problem war.
jaja, da laeuft noch so manch anderes drauf
Stimmt. In der Regel macht es Sinn Mempool Goggles auf “Inscriptions“ zu beschraenken. Dann stechen sofort die grossen 400 KB Transaktionen heraus die aber nur als 100 vKB gezaehlt werden und irgendein Bild einbetten. Ein Block der aus lauter solchen Transaktionen besteht blaeht somit bis zu 4 MB auf.
Um ein paar zu nennen:
CVE-2019-25220 - Memory DoS due to headers spam
CVE-2020-14198 - Remote DoS
CVE-2024-52915 - Memory DoS using huge INV messages
CVE-2024-52917 - Infinite loop bug in the miniupnp dependency
CVE-2024-52918 - Crash using malicious BIP72 URI
CVE-2024-52919 - Remote crash due to addr message spam
CVE-2024-52920 - DoS using huge GETDATA messages
wie gesagt, mein
dass du dich mal nicht wunderst. Ich denke Deutschland hängt da global gesehen bei der Digitalisierung weit hinterher. Und wie gesagt, nicht die Internet-Leitung ist der limitierende Faktor, sondern die Validierung der Blöcke, also im Grunde genommen die Hardware der node.
sind auch nur Daten 
