Wenn ich die Protokolldefinition richtig verstanden habe sollte es möglich sein, bei Blöcken von denen alle Out Salden in In Transaktionen nachfolgender Blöcke aufgetaucht sind die Transaktionen zu löschen, da der nachfolgende Block Hash nur vom Merkle Root abhängt. Danach bleibt nur noch der Blockheader übrig was bei alten Transaktionen ausreichen sollte. Die Kette zum Anfangsblock bleibt damit immer noch gültig, es muss nur sichergestellt werden, dass keine aktuellen Salden "verschwinden".
Oder habe ich hier einen Denkfehler drin?!
Topic: Steigende größe der Block-Dateien? (Read 1434 times)
Einerseits gibt es derzeit noch ungenutzte Möglichkeiten diese Datenbank weiter zu verkleinern (nach ersten Tests um zwischen 30 und 70%), andererseits müssen in Zukunft nur Miner die gesamte Kette geladen haben.
Man könnte auch theoretisch einer "öffentlichen" Kette vertrauen und nur Updates ab einem gewissen Punkt von dort beziehen.
Generell hast du allerdings recht, wenn Bitcoin unendlich lange läuft, werden unendlich viele Blöcke generiert die auch entsprechend unendlich viel Speicher brauchen.
Allerdings kommt es darauf an, ob Speicher schneller billiger wird als die Kette wächst oder nicht, ob sich das auf längere Sicht lohnt.
Daher zahlt man ja auch teilweise transaction fees um die Miner zu unterstützen, die die Kette _immer_ geladen (und gespeichert) haben müssen.
Man könnte auch theoretisch einer "öffentlichen" Kette vertrauen und nur Updates ab einem gewissen Punkt von dort beziehen.
Generell hast du allerdings recht, wenn Bitcoin unendlich lange läuft, werden unendlich viele Blöcke generiert die auch entsprechend unendlich viel Speicher brauchen.
Allerdings kommt es darauf an, ob Speicher schneller billiger wird als die Kette wächst oder nicht, ob sich das auf längere Sicht lohnt.
Daher zahlt man ja auch teilweise transaction fees um die Miner zu unterstützen, die die Kette _immer_ geladen (und gespeichert) haben müssen.
Also ich denke das es richtig ist das der Client immer die Blocks aus dem Netz lädt. Aber ich denke das diese Datei entweder nicht zu groß wird oder irgendwann mal das Netz sich die Blocks teilt. Jedoch gibt es ja immer noch die Möglichkeit den Clien zu verändern so das eine andere Möglichkeit eingebaut werden könnte, damit neue User später nicht Ewigkeiten brauchen bis sie die Bitcoins nach der erst Installation benutzen können und nicht bei jedem die Platte platzt.
MFG Pikkker
MFG Pikkker
hi, beschäftige mich seit ein paar wochen intensiver mit bitcoins, habe eine kleine frage zum techn. hintergrund.
liege ich richtig wenn ich sage jeder client (ausser der bitcoinj glaube ich?) muss alle blocks downloaden um teil des netzwerkes zu werden und dies auch immer weiter tun um das netzwerk aufrecht zu erhalten?
soweit ne gute sache, aber, die block-datei (so nenn ich mal die daten die auf jede einzelne lokale festplatte geschrieben werden) sind jetzt bei welcher größe? ich habe gelesen ca. 300mb.
diese datei/dateien werden doch immer größer, auch je mehr wallet-addressen registriert werden/bei jeder transaktion etc.? gibts eine techn. möglichkeit bzw. ist ein mechanismus vorgesehen diese datei/dateien in der größe zu reduzieren?
wenn ich alles richtig verstehen müsste diese datei/dateien irgendwann mehrere hundert GB bzw. irgendwann TB erreichen ... oder?
liege ich richtig wenn ich sage jeder client (ausser der bitcoinj glaube ich?) muss alle blocks downloaden um teil des netzwerkes zu werden und dies auch immer weiter tun um das netzwerk aufrecht zu erhalten?
soweit ne gute sache, aber, die block-datei (so nenn ich mal die daten die auf jede einzelne lokale festplatte geschrieben werden) sind jetzt bei welcher größe? ich habe gelesen ca. 300mb.
diese datei/dateien werden doch immer größer, auch je mehr wallet-addressen registriert werden/bei jeder transaktion etc.? gibts eine techn. möglichkeit bzw. ist ein mechanismus vorgesehen diese datei/dateien in der größe zu reduzieren?
wenn ich alles richtig verstehen müsste diese datei/dateien irgendwann mehrere hundert GB bzw. irgendwann TB erreichen ... oder?
Jump to: