Warum die gesamte History kennen bei Bitcoin und nicht nur Snapshots?

Es gibt aktuell keine relevante Alternative, weil es schlicht nicht nötig ist, solange Bitcoin fehlerfrei arbeitet. Die Welt braucht keine zwei Bitcoin.

Gäbe es jedoch einen Inflationsbug, würde der Schrei nach einer besseren Alternative groß werden. Diese Alternative könnte auch ein Hardfork von Bitcoin sein.

Als Beispiel kann man hier Ethereum und Ethereum Classic nennen. Als es bei Ethereum zu einen Bug kam, wurde entschieden einen Hardfork durchzuführen. Die originale Blockchain wird weiterhin in Ethereum Classic verwendet.

Klar hätte dies Vorteile, aber auch Nachteile und diese diskutieren wir ja gerade. Und per Definition von Bitcoin überwiegen diese Nachteile. Demzufolge ist ein System ausschließlich mit Snapshots, anstatt einer vollständigen Blockchain, mit der Philosophie von Bitcoin nicht vereinbar.

1 „Gefällt mir“

Naja in gewisser Art und Weise schon, da Bitcoin deswegen nicht skaliert. Was auch erstmal nicht das Problem ist imo, ich frage mich nur ob dieser trade off Sinnvoll ist und wie ich das verstehe speichert man die History nur damit man sich im schlimmsten Fall (Bug in der Vergangenheit) gegen Bitcoin entscheiden kann und das es aus meiner Sicht keine dezentrale Alternative gibt, muss man Bitcoin so und auch so verwenden, ob da nun was in der Vergangenheit war oder nicht. Also wenn man die History eh nicht ändern kann/will und sowieso nur Bitcoin eine Option ist, braucht man doch nicht 100% der History speichern…

Man kann doch aber niemals wieder ein Netzwerk so dezentral wie Bitcoin aufbauen, da PoW sehr angreifbar ist, wenn es klein ist und somit gibt es auch keine Mögliche Alternative. Alle Hardforks von Bitcoin sind zentralisiert oder haben sehr wenig hashrate. Wenn ich jetzt aber ein Inflationsbug von 2016 finden würde, wäre dieser auch in fast allen Hardforks (Außer in Bitcoin XP) und solch ein Bug hätte sich sowieso ausgewirkt oder wir haben mit ihm weiter gemacht und es nicht bemerkt, also brauchen wir doch auch nicht die gesamte history. klar es passt 100% zu Bitcoins Philosophie, aber keinen Nutzen, außer neue Leute möglicherweise zu überzeugen das es noch nie solch einen Bug gab und wer mach sich schon die Arbeit als newbie erstmal die gesamte History bis zum Genesis Block zu verifizieren…

Wie soll ich noch erklären, warum es notwendig ist??

Mehr fällt mir nicht mehr ein: https://bitcoin.org/bitcoin.pdf

Was verstehst du unter skalieren?

1 „Gefällt mir“

Ja man braucht den Hash vom letzten Block usw. aber es gibt auch Projekte, die mit Snapshots arbeiten oder so was in der Art und deswegen denke ich mal das, dass nicht das Problem wäre.

Ich meine skalieren in Tps, mehr/größere Blöcke etc.

Das hängt davon ab wie weit ein solches neues System von dem bereits Etablierten entfernt ist. Angenommen Bitcoin enthält einen Inflationsbug. Dann wäre es vermutlich relativ einfach einen Großteil das Bitcoin Netzwerke davon zu überzeugen Bitcoin 2.0 zu verwenden.

Dieses neue System müsste im Prinzip zwei Punkte berücksichtigen, um akzeptiert zu werden: Zum einen muss der Bug behoben sein. Zum anderen darf der Mining Algorithmus nicht verändert werden. So könnte relativ einfach die vorhandene Mining Hardware in das neue System überführt werden. Dann wäre quasi über Nacht das neue System das sicherste Netzwerk und das Alte so unsicher wie die bereits vorhandenen Alternativen (Bitcoin Cash, etc.).

Jeder, der eine Node neu aufsetzt, macht automatisch genau das.

1 „Gefällt mir“

Du gehst davon aus das jetzt oder in den letzten Monaten ein Bug aufgetreten wäre und da stimme ich dir zu aber ich hab mich auf die History bezogen, welche ja gespeichert wird, also vom Genesis Block aus und niemand würde die blockchain ab 2016 forken oder zurück drehen…

Würde eine Node einen Inflationsbug merken? wenn ja ändert das einiges…

Ob das niemand machen würde oder doch, kann nur vermutet werden. Ich würde behaupten dass es gemacht wird sofern es ein Großteil akzeptieren würde.

Das kommt auf die Version an. Aktuell würde keine Node einen Bug finden wo alle anderen Nodes keinen gefunden haben, da jeder den gleichen Validierungssprozess verwendet.

Aber eine erfolgreiche Validierung erfüllt ja bereits den Zweck, dass man niemanden vertrauen musste, um zu bestätigen dass das Netzwerk korrekt arbeitet.

1 „Gefällt mir“

Du glaubst wirklich das man die 6 Jahre oder mehr zurück dreht und somit double spends akzeptiert? welches auch ein Versprechen von Bitcoin ist.

Also ist es zu 100% sicher das es keinen Inflationsbug in der Vergangenheit gab? sonst hätte es eine Node bemerkt.

Da hast du vermutlich recht.

Der eine Bitcoin hat mit dem Anderen nichts zu tun. Es wäre somit nur ein indirekter Double Spend.

Das habe ich versucht über @Makowski Antwort zu beantworten. Aktuell besagt die Technik dass kein Inflationsbug bekannt ist. Dies könnte aber nur daran liegen dass die aktuellen Verifizierungsprozesse selbst fehlerhaft sind. In der Zukunft könnte durch bessere Algorithmen auffallen dass es doch einen bis dato unentdeckten Inflationsbug in der Vergangenheit gegeben hat.

Vermutlich ist dies aber sehr unwahrscheinlich.

1 „Gefällt mir“

Das hast du falsch verstanden. Es gibt keinen Grund so weit zurückzurollen. Die Chain bis zum aktuellen Block stimmt so. Ein Inflationsbug ändert nichts an der Historie. Ein Inflationsbug schüttet über eine Transaktion zu viel Geld aus. Das merkt man sofort. Das heißt auch, dass bisher (bis auf 2010, glaube ich) kein Inflationsbug auftrat.

1 „Gefällt mir“

Das wäre doch bei allen Projekten so, auch mit snapshot etc. oder?

Also ist es 100% sicher das es kein Inflationsbug gegeben haben kann bis heute und man speichert die gesamte history um das zu beweisen und das wäre nicht möglich mit einen snapshot model?

Es gab einen am 15. August 2010. Und das ist aufgefallen, weil die Geldmenge zu jedem Zeitpunkt transparent ist. Der Bug wurde behoben, die Blockchain ein paar Stunden zurückgerollt – fertig. Heute wären die Auswirkungen natürlich wesentlich schlimmer, aber wenn dadurch Bitcoin nicht mehr dem vereinbarten Konsensus (insb. der Menge von 21 Mio. Bitcoin) entspräche, würde wohl auch heute noch zurückgerollt werden.

Warum die gesamte Historie aller Blöcke benötigt wird, erkläre ich jetzt noch ein allerletztes Mal. Ohren auf! Würde man nicht die komplette Historie aufheben, dann könnte man die Verkettung von Blöcken, a.k.a. Blockchain nicht verifizieren. Man benötigt alle Transaktionen dafür. Jede einzelne. Seit Anbeginn. Komplett. Ohne Ausnahme. Ohne Blöcke keine Blockchain.

Es existieren nicht-ausgegeben Coins bereits aus den ersten Blöcken. Was willst du damit bei einem Snapshot Modell machen? Die müssen ja mit in den Snapshot. Das geht so weiter bis heute. Ich nehme an, dass aus fast allen Blöcken mindestens eine Transaktion bis heute noch nicht ausgegeben wurde. Nun gut, dann verwirft man eben alle bereits ausgegebenen Transaktionen und merkt sich nur noch die nicht-ausgegebenen. Genau das passiert beim pruning. Das ist genau der Snapshot nach dem du fragst.

Weiter. Angenommen du hast eine Transaktion getätigt, die nicht mehr Teil des Snapshots wäre, möchtest aber nachweisen, dass diese Transaktion passiert ist. Wie machst du das bei einem Snapshot Modell?

Ab jetzt antworte ich nur noch in Satoshi Zitaten.

2 „Gefällt mir“

Dem ist nichts hinzuzufügen.

1 „Gefällt mir“

@Makowski Profilbildänderungen bitte immer vorher mit uns absprechen, das verwirrt sonst zu sehr :sweat_smile:

@Sven:
Deine Argumentation, dass Bitcoin wegen der Aufbewahrung aller Blöcke nicht skaliert, ist etwas lückenhaft. Bitcoin skaliert ja nicht besser, nur wenn man jetzt Snapshots einfügt. Man müsste zusätzliche Parameter (Blockgröße, Blockzeit) damit die Snapshots auch einen Sinn haben. Da diese beiden Parameter in naher Zukunft wohl nicht geändert werden, machen Snapshots so keinen Sinn und würden die Historie, wie bereits erläutert wurde, nur über den Haufen werfen und eine komplette Verifizierung unmöglich machen.

Mit deinem Vorschlag wärst du bei BigBlock-Projekten alá Bitcoin Satoshi Vision oder Bitcoin Cash besser aufgehoben, denn die hätten eher einen Vorteil, wenn man Snapshots hinzufügen würde. (dass das mit dem Prinzip des UTXO nicht umsetzbar ist, wurde ja schon angedeutet)

2 „Gefällt mir“

Sorry, ich brauchte Augen.

3 „Gefällt mir“

Was wäre der trade off von solchen zusätzlichen Parameter (Blockgröße, Blockzeit)?

Mir geht es nicht darum irgendein Projekt besser oder schlechter zu finden. Da ich immer viel mit Nano/Iota Leuten auf twitter diskutiere, wollt ich das ganze Thema verstehen und die trade offs dahinter und wie ich das verstehe braucht man die gesamte history, da es sonst nicht anders möglich ist mit dem UTXO Model alles nach zu vollziehen und neuen Leuten zu beweisen das es nie einen Inflationsbug gab, wenn eine Node solch einen Bug zu 100% finden würde, wäre das ein guter Grund die History zu speichern, wenn das ein Mensch/newbie selber alles prüfen müsste nicht. Danke für eure Hilfe!

Hier meine Gedanken, erst zur theoretischen und praktischen Machbarkeit, dann zur Sinnhaftigkeit. Allerdings ohne dass ich mich bei Bitcoin, IOTA oder anderweitig ernsthaft damit beschäftigt hätte. Vielleicht übersehe ich also auch Entscheidendes.

Theoretisch denke ich schon, dass das auch bei Bitcoin möglich wäre. Wenn man zu einem Zeitpunkt das komplette UTXO Set, den aktuellen Block und eine Hand voll Parameter kennt, hat man alle relevanten Informationen für den weiteren Betrieb. Das heißt auf Basis eines derartigen Snapshots könnte man von da an weiterarbeiten.

Praktisch würde das bedeuten, dass man das Bitcoin Protokoll so anpassen müsste, dass man einen bestimmten Snapshot als Basis festlegt, der von da an durch alle Nodes anerkannt wird. Da die Konsens-Regeln signifikant betroffen wären, wäre das mit Sicherheit kein reibungsloser Hard Fork. Abgesehen davon würde man dafür zumindest heutzutage keine Mehrheit bekommen, da man nicht viel gewinnt (s.u.).

Bei der Festlegung des Snapshot Zeitpunktes muss man auf jeden Fall ein ganzes Stück in die Vergangenheit zurückgehen. Die Sicherheit von Bitcoin beruht entscheidend darauf, dass die Blockchain mit dem größten Proof of Work gültig ist.
Es könnte immer sein, dass gerade zwei Chains parallel gemined werden. Entweder bösartig, oder gutartig (zwei parallel gefundene Blöcke).
Der Snapshot Zeitpunkt sollte also mindestens ein paar Wochen oder Monate zurückliegen. Speichern müsste man also ab dem Zeitpunkt des Konsens-Wechsels nur noch den Snapshot, sowie die Blöcke die von da an gemined wurden. Man würde auf keine Fall den Snapshot heute durchführen und direkt darauf aufbauen.

Was würde man gewinnen?

Die Skalierung von Bitcoin würdest du denke ich dadurch verbessern wollen, dass man wegen der geringeren Anzahl zu speichernder Blöcke stattdessen die Blöcke vergrößert.

Erstens müsste man so einen Snapshot also nicht nur einmal, sondern regelmäßig durchführen. Das wäre jedes Mal ein riesen Akt, kaum vorstellbar.
Man könnte es auch fest ins Protokoll integrieren. Das wäre aber dann eine noch größere Änderung und würde evtl. auch neue Angriffsmöglichkeiten schaffen.

Zweitens muss der Snapshot wie gesagt immer einige Zeit zurückliegen. Man könnte den Speicherbedarf vielleicht bestenfalls um den Faktor 10…100 verringern. Wenn man stattdessen die Blöcke um denselben Faktor vergrößern würde, wegen mir sogar um den Faktor 1000, hätte man trotzdem keine ausreichende Skalierung für eine Weltwährung.
Wenn also trotzdem zusätzliche Second Layer notwendig sind, warum dann überhaupt stark im Mainlayer skalieren? Geringe, notwendige Skalierung ist auch durch zukünftige geringe Blockvergrößerungen möglich.

Drittens gibt es physikalische und informationstechnische Grenzen, die bzgl. Transaktionen pro Sekunde in einem sicheren, globalen, für jeden zugänglichen P2P Blockchain Netzwerk nicht überschritten werden können. Egal wie groß du die Blöcke machst, werden die TPS ohne Second Layer niemals reichen. Siehe z.B. meine grobe Abschätzung hier.

Viertens beruht Bitcoins Sicherheit darauf, dass die Miner heute (wenig Fees) und in Zukunft (wenig Subsidy) einen ausreichenden Anreiz haben zu minen. Eine Blockgrößenerhöhung müsste man also u.a. auch auf jeden Fall bzgl. Einfluss auf die Blockrewards untersuchen. Siehe Thread hier.

3 „Gefällt mir“

Sehr interessanter Beitrag, der mir sehr in Sachen Verständnis weiter geholfen hat!

Dem würde ich zustimmen aber 2.Layer wie Lightning etc. brauchen auch Main Layer Transaktionen und könnte nicht ein wichtiger Knotenpunkt im LN eine Art Kettenreaktion auslösen, so das viele ihren Channel schließen und Transaktionen finalisieren müssten?

1 „Gefällt mir“

Das Thema ist hier schon recht ausgelutscht, es gab in letzter Zeit wieder einige Threads dazu.

Zuerst einmal muss Bitcoin so viel Adoption erfahren, dass die Nachfrage nach Transaktionen groß genug ist, um die irgendwann vernachlässigbare Subsidy zu ersetzen. Die Gebühren werden also in den nächsten Jahrzehnten hoffentlich mindestens um den Faktor 10…100 steigen.

Wenn die Gebühren tatsächlich zu groß werden sollten, so dass sich trotz Batch-Transaktionen keiner mehr das gelegentliche Öffnen und Schließen von Channels leisten kann, wird man sicher auch Blockgrößenerhöhungen diskutieren.

Dazu auch interessant:

Der Einfluss der Blockgröße auf die insgesamt enthaltenen Gebühren ist auch nicht trivial. In dem einen von mir oben verlinkten Thread hatte @mowtan ein Paper dazu verlinkt (hier).

Übrigens beziehen sich meine Gegenargumente im letzten Beitrag auf eine Blockchain mit PoW. In einem DAG-basierten Netzwerk kann das vielleicht anders aussehen.