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.
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.
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.
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.
Dem ist nichts hinzuzufügen.
@Makowski Profilbildänderungen bitte immer vorher mit uns absprechen, das verwirrt sonst zu sehr 
@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)
Sorry, ich brauchte Augen.
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.
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?
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.