also wenn man ne HDD nutzen möchte, was immernoch geht, selbst mit einem Raspi 4gb ram, dann kann man die Synchronisierung woanders machen und dann nen Klon auf seine HDD machen. Gibt sogar nen Tutorial hier irgendwo. Also alles imemrnoch kein Problem
möchte ich in Zukunft auch noch machen, steht auf der Liste ;-)
ich glaube hier haben wir 2 unterschiedliche Definitionen auf „aufgebläht“. Inscriptions sind zuerst einmal spendable. Ja sie ahben Daten angehängt, sind für Bitcoin aber nicht schädlich, weil sie ausgegeben werde können.Sobald die Coins wieder verschickt werden, wird daraus eine normale Transaktion und die Daten sind nicht mehr angehangen. Das ist also kein Dauerzustand sondern ein fluider. Was ich mit UTXO-Bloat gemeint habe, ist der der am Ende unspendable ist, also UTXOs die nicht mehr ausgegeben werden können und genau diese sind die gefährlichen. Diese blähen das Set nämlich auf und werden nie wieder rausgeholt aus dem Set, weil man sie nicht mehr ausgeben kann.
Dass die meisten (mich eingeschlossen) kein Interesse an NFTs haben ist offensichtlich. Aber nur weil es Welche gibt, die die Möglichkeit zur Dateneinbettung für NFTs verwenden, soll man jetzt Daten an sich verhindern?
wofür, um fakepubkeys und somit den UTXO-Set Bloat erst Recht zu forcieren?
woher möchtest du dir herausnehmen zu beurteilen, dass es nicht noch weitere Adoptionen mit Hilfe von Daten auf der Blockchain geben kann?Als ob du jede erdenklich mögliche Idee, die eine Datenimplementierung nötig hat, evaluiert hast. Ist ein bisschen abgehoben meinst du nicht?Vielleicht kommt demnächst der nächste um die Ecke und implementiert über diesen Datacarrier etwas, was eine neue Art 2nd Layer einführt. Oder etwas anderes, was Bitcoin von Nutzen sein könnte.
Mit Utreexo hab ich mich noch nicht beschäftigt, kann ich nichts zu sagen.
wie gesagt, siehe meine Beiträge zu Inscriptions. Ja der UTXO-Set ist größer geworden, aber das ist alles noch gesund und vor allem spendable.
ich meinte die Blöcke ohne Segwit. Und selbst die mit segwit, bleiben bei höchstens 4 MB limitiert. Also alles gut. Du selbst hast ein Bild mit dem average Blocksize gepostet, der anscheinend bei 1,59 MB liegt. 1,59 MB alle 10 min ist gar nichts.
okay, da hast du Recht. So ne alte Version sollte man dann lieber nicht laufen lassen.
war aber darauf bezogen. weil es anscheinend um Speicherplatz ging. Wenn Speicherplatz das Problem für jemanden ist, was glaube ich kaum jemanden betrifft, dann kann man als Lösung immernoch eine pruned node laufen lassen.
natürlich kann man dann auch weiter Spam hochladen, das bestreitet Luke nicht.
Selbstverständlich kann dann weiterhin auch das zu einem UTXO-Set bloat führen
aber (ich verstehe es so) hätte man diesen Github Issue auch umgesetzt dann könnte man das Problem auch handlen
Wir denken halt, wenn es umgesetzt worden wäre, dann gäbe es keine Möglichkeit mehr über z.B. OP-RETURN oder über Inscriptions Daten zu verknüpfen und dann werden die Leute, die Daten verknüpft haben wollen, vermehrt auf fake-pubkeys ausweichen, was im Grunde genommen dazu führt, dass das UTXO-Set kontinuierlich aufbläht und zwar mit den schadvollen UTXOs, die man eben nicht mehr ausgeben kann. Die unspendables sind eben schädlicher, als die die man noch ausgeben kann.
Sagen, wir mal, das OP_RETURN so bleiben würde wie es war bevor Core V30, dann würden Leute wie du sagst, dann noch immer über fake-pubkeys die Daten in den UTXO-set hochladen (schädliche Daten & Unspendables)
Das hört sich für mich nach einem anderen Problem an, als anstatt den OP_RETURN auf unbegrenzte Speicherkapazität zu stellen.
Weil OP_RETURN war so perfekt wie es war. FakePubkeys haben einen anderen Exploit benutzt.
Dieser Exploit gehört gefixed und OP_RETURN gehört in Ruhe gelassen.
So verstehe ich das.
Zusätzlich für die weiteren Leser bezüglich BIP110
Ich habe hier Luke Dashj gefragt über BIP110 - wollte es nur teilen
genau. Deswegen haben die Bitcoin Core Leute auch das Limit aufgehoben. Damit die Leute auf OP_RETURN ausweichen können, anstatt fakepubkeys zu nutzen.
es ist nicht unbegrenzt. Der begrenzende Faktor ist immernoch der Block selbst.
ja eben nicht. es war nicht perfekt. weil, die Leute auf den anderen „exploit“ wenn du es so nennen möchtest ausweichen mussten.
Du kannst fakepubkeys nicht fixen, weil du zwischen echten pubkeys/adressen und datenmüll nicht unterscheiden kannst. das habe ich aber weiter oben schon geschrieben.
ja und hier ist er mal wieder nicht ehrlich.er sagt zwar es wäre möglich aber im gleichen Satz sagt er, dass es anders als Hochladen von Daten wäre. Aber das ist eben nicht anders. ja es ist ein andere Vorgehensweise, aber es sind beides daten die auf die Chain geladen werden.
Ich hatte diese Diskussion aber schon mit so Vielen. Bin auch ehrlich gesagt müde vom wiederholen. Ich bin mir sicher, dass 110 sich nicht durchsetzen wird. Du kannst gerne wechseln und zu Lukes Jünger werden. Wie Jesus führt er sich jedenfalls schon auf
Ich klinke mich jedenfalls aus. Es ist Wochenende und ich hab noch einiges vor ;-)
In meinen Augen ist Bitcoin frei und zensurresistent und dafür werde ich mich immer einsetzen.
Der Output aus dem UTXO-Set verschwindet, aber die Transaktion+Witness in der Blockchain bleibt auf ewig gespeichert.
Ja, find ich auch nicht toll. Aber wie gesagt: Utreexo loest das Problem.
Wenn es nach mir ginge wuerde ich auch nicht den BIP-110 Ansatz gehen, sondern stattdessen einfach den Witness-Discount mittels Soft Fork entfernen. Somit haetten Inscriptions keinen 75% Rabatt mehr und der Gebuehren-Markt waere nicht mehr verzerrt.
Dennoch wenn man aus welchem Grund auch immer beweisen moechte dass gewisse Daten zu einem bestimmten Zeitpunkt existiert haben, muss man diese nicht in Gaenze in die Chain schreiben. Es genuegt ein 32 Byte kleiner SHA256 Hash hinter einem OP_RETURN. Die eigentlichen Daten koennen extern gespeichert werden.
Also da ich aktuell nicht sehe wie das Einbetten grosser Daten in Scripts die garnicht ausgefuehrt werden auf der Chain Sinn machen wuerde, stehe ich einem temporaeren BIP-110 Soft Fork fuer ein Jahr auch offen gegenueber.
Das summiert sich.
1.59 MB Bloecke fuer ein Jahr: 52560 * 1.59 = 83.57 GB
1 MB Bloecke fuer ein Jahr: 52.56 GB
ja aber dafür haben wir uns schon entschieden und zwar 2017 mit segwit. wir haben uns bereits entschieden ob wir max 4 MB Blöcke haben wollen. wir haben bereits evaluiert dass im 21 Jahrhundert ein Zuwachs von Durchschnittlich 1,59 MB pro Block easy peazy ist und Festplattenspeicher NICHT das Problem ist. Vor allem nicht bei den Mengen. Du kommst immer wieder zurück zu den gleichen Argumenten als würdest du es nicht verstehen wollen. Hast die Rechnung sogar selbst gemacht.
was summiert sich denn da?willst du nen softfork machen wegen ~30 GB im Jahr, was bereits 2017 als handhabbar eingestuft wurde?das sind 3 TB in 100 Jahren, bis dahin kaufst du dir ne 5 Petabyte SSD Platte für 5 €. Herrje…
du schmeißt hier mit Links um die Ecke wie vorher mit dem github-thread und meinst wir müssen das alle lesen. ich hab mir die mühe gemacht. aber vielleicht kannst du einmal kurz erklären wie Utreexo funktioniert anstatt uns wieder mit Arbeit zu überhäufen. Ich habs nicht gelesen und hab auch nicht jedes mal die Zeit dafür nur weil der X-te BIP110-Unentschlossene mal wieder irgendwo was aufgeschnappt hat. Ich glaube nicht das das Problem mit fakepubkeys gelöst werden kann, weil man wie ich zum wiederholten male bereits oben geschrieben habe, dass man nicht zwischen einem public key/hash und Daten unterscheiden kann. Aber vielelicht kannst du uns ja eines Besseren belehren.
Und wie gesagt, es gibt Bitcoiner, die möchten Daten auf der Blockchain verwenden, die wird es immer geben. Wenn du Daten verhinderst, werden diese Menschen andere Wege finden wie eben über die schädlichen Alternativen. Das ist Evolution. Du kannst dich die ganze Zeit mit Antibiotika vollstopfen was am Ende dazu führt, dass du multiresistente Keime züchtest die dich direkt ins Grab befördern.
Eine Node mit Utreexo muss nicht mehr das komplette UTXO-Set speichern.
Stattdessen werden nur die Wurzeln eines Merkle-Forest gespeichert die mit jedem neuen Block aktuell gehalten werden. Dies bildet den Zustand des ganzen UTXO-Set in nur ein paar Hashes ab.
Zusaetzlich zu einem neuen Block erfordert eine Utreexo-Node auch die Beweise fuer die ausgegeben UTXOs. Diese Beweise prueft die Node dann gegen den Merkle-Forest. Das Uebermitteln der Beweise erfordert minimal mehr Netzwerk-Traffic.
Die Anzahl der zu speichernden Hashes waechst nur logarithmisch mit der Anzahl der UTXOs: O(\log_2{n})
Statt ein 11 GB UTXO-Set zu speichern, speichert man nur ca. 1 KB an Hashes.
Es muss also nicht mehr jeder Bitcoiner das ganze UTXO-Set fuer alle speichern. Es genuegt nur die Beweise fuer die eigenen UTXOs zu speichern und aktuell zu halten.
interessant. muss ich mir mal anschauen. so kann das UTXO-Set schlanker gehalten werden. Es verhindert aber keine fakepubkeys so wie ich das jetzt herauslese. die bleiben trotzdem für immer im UTXO-Set bzw. dann mit dem neuen System die hashes davon.
Ja, ziemlich coole Sache. Der Kopf dahinter, Tadge Dryja, ist uebrigens auch einer der Autoren des Lightning Network Papers.
Fake Public Keys und Fake Script-Hashes werden nicht verhindert, aber sie fallen dann halt kaum mehr ins Gewicht, weil der Speicherplatz-Bedarf nur logarithmisch waechst.
Oh man, tut mir leid das ich jetzt so eine Riesen Diskussion entfacht hab, ich wollte lediglich wissen was es damit auf sich hat und nicht das zwei Welten aufeinander prallen. wir sind doch alle bitcoiner und miner
Auf der einen Seite ist es gut, dass es verschiedene Meinungen gibt und es keine blinden Flecken gibt.
Auf der anderen Seite ist es für mich die einzige reale (wenn auch sehr kleine) Gefahr für Bitcoin, dass die Fronten der Bitcoiner irgendwann so verhärtet sind, dass Bitcoin kaputtgeforkt wird.
Du musst für dich einfach entscheiden, ob es dir wichtiger ist, deine Node von Müll und Spam zu befreien, wenn dir das ein gutes Gefühl gibt oder ob es dir wichtiger ist, dass das Netzwerk möglichst dezentral und unzensiert bleibt.
Ich glaube Bitcoin hat kein Problem und ist nicht angreifbar, sonst wäre es schon lange passiert, Bitcoin muss nicht getettet werden, deswegen bleibe ich bei Core für maximale Dezentralität, Freiheit und wenig Veränderungen.
Das hast du richtig gut beschrieben, auch wenn ich vorher nicht so genau wusste warum es zwei verschiedene Versionen gibt ( Core und knots ) ich hatte zu meiner Anfangszeit und absolute Leihezeit mich für knots entschieden grade weil ich mehr Möglichkeiten hatte meine blocke zu gestallten ohne aus dem Raster zu fallen weil ich nicht so viele Daten durch lassen möchte. Bitcoin ist für mich ein sehr starker coin und wenn ich die Möglichkeit habe ihn sauber zu halten, grade im Hinblick das bitcoin als stärkere Währung bzw. Zahlungsmittel gegenüber dem FIAT gelten möchte, wollte ich jede Möglichkeit nutzen um ihn sauber zu halten aber halt ohne aus dem Raster zu fallen
Dann mach das, aber wenn wir ihn sauber halten müssten, damit er funktioniert, wäre er kein sehr starker Coin.
Ich frage mich, in Extremen gedacht, welche Richtung zu einem wertvolleren Netzwerk werden würde.
Core, die mehr zulassen, dafür dezentraler in Entwicklung und Entscheidungen sind und jedem die Freiheit geben Bitcoin zu nutzen.
Oder Knots, die, um das Netzwerk endgültig sauber zu halten ein zentrales Komitee brauchen, das entscheidet, was aufgenommen wird und was nicht. Unerwünschtes bleibt weg, nur Zahlungen sind erlaubt, vielleicht kann das Komitee sogar gestohlene Coins zurückholen oder Terroristen ihre Coins einfrieren…
Letzteres (Knots) erinnert mich doch stark an unser derzeitiges Bankensystem.
genau diese Fragen stelle ich mir auch und ich denke wenn wir es wie die Knotzis machen, wird Bitcoin sich nicht eiter entwickeln und wir werden nicht die Massen onboarden wie wir es gerne hätten. Dann bleibt das Netzwerk klein. Es bleibt bei 7 Transaktionen pro Sekunde. Lightning funktioniert zwar, aber hat seine Probleme mit dem Öffnen und Schließen von Kanälen.
Mit einem zensurresietenten Netzwerk, was auch Daten zulässt, wird es immer mehr Möglichkeiten geben 2nd Layer und weitere Adoptionen zu entwickeln, die Bitcoin wertvoller machen werden und es eben wirklich zu einem Zahlungsmittel für ALLE machen wird. Adoption direkt im Keim zu ersticken ist wenig förderlich. Bitcoin ist für alle da und da wir Menschen so unterschiedlich sind, gehen die Meinungen natürlich auch weit auseinander. Man muss sich arrangieren und nicht direkt alles verbieten. Gerade so etwas wie Datenanhänge, die viel Potential haben können aber trotzdem limitiert werden durch die Blockgröße, sollte kein Problem für Bitcoin darstellen sondern tatsächlich ein Feature. Die Blockgröße beschränkt das sinnlose Anwachsen der Blockchain und das ist gut so. Alles andere regelt der Markt.
Knots ändert absolut garnichts, außer das die unerwünschten Daten nicht über OP in die Blockchain aufgenommen werden, was man prunen also löschen kann.
Sondern in Knots Welt dann über andere Wege, wie Fake Public Keys, die man nicht löschen kann und im UTXO Set jeder Node landen und jede Node belasten.
Aber genau das ist ja was Knots nicht will, also brauchen sie einen Fork um nachhaltig Spam und unerwünschtes aus der Blockchain zu verbannen.
Aber wer entscheidet dann, was ein Fake Public Key ist und was ein erlaubtes Skript ist und was man reinschreiben darf. Irgendeine zentrale Stelle muss dann sagen, wer Bitcoin für was nutzen darf und wer nicht, und das ist dann nicht mehe der freie dezentrale Bitcoin dem ich vertrauen würde.
Das kann ich sogar gut verstehen, nur ist da nicht schon die Rede von gewesen ( ich weiß jetzt nicht mehr wie der Stand der Dinge ist) das du als Node Betreiber auch welche auf den Zopf bekommst weil du „illegale“ Daten verteilst egal wo die herkommem?
;-)
wir sind doch alle bitcoiner und miner 