Ich verstehe, dass du das Format Blocktrainer eher auf Neulinge ausrichtest und ein möglichst breites Publikum ansprechen möchtest, allerdings wäre es cool wenn es auch ein Format geben würde in welchem du ein bisschen komplexere Themen behandeln würdest. Zum Beispiel ca. einmal im Monat ein art Blocktrainer Pro bei dem ein gewisses Grundwissen vorausgesetzt wird. Dies wäre für die Leute gedacht die wissen wie ein Ledger, Tangle, Blockchain etc. funktionieren oder wie man Kryptos kauft sei das jetzt auf ner App oder im internet oder sonst wie. Ich denke ich bin nicht der einzige der bei manch einem Video von dir die Hälfte überspringt weil es vielfach einfach immer wieder die gleichen Basic Sachen sind die du immer und immer und immer wieder erklären (musst?). Ich weiss wie viel Arbeit du in deine Videos steckst und finde dies jeweils Schade.
Nun habe ich aber doch auch noch ne Frage da, das hier schliesslich Frag den Trainer ist:
Betreffend Blockgrösse sagst du ja immer, dass grössere Blöcke zu Zentralisierung führen wegen dem Speicherplatz. Könnte man jetzt nicht wenn man eine Node betreiben möchte im Bitcoin zum Beispiel sagen? OK meine Node muss nicht die KOMPLETTE Blockchain speichern sondern nur einen Teil. Angenommen wir wären nach dem halving bei Block 638’500. Man könnte doch auch nur die Blöcke seit dem Halving speichern? Dies sind immerhin 8’500 Blöcke und es kann davon ausgegangen werden dass die Blockchain nicht mehr überschrieben wird? So müsste man die ersten 630’000 Blöcke nicht mehr speichern und würde extrem Speicherplatz sparen.
Große Blöcke führen nicht zu Zentralisierung wegen dem benötigten Speicherplatz. Du kannst den Speicherplatz für eine Fullnode deutlich unter 100GB für die nächsten Monate/Jahre halten, indem du einfach deine Node umstellst auf pruning. Wenn du in deine bitcoin.conf „prune = 1“ einträgst bevor du die Node das erste Mal startest, dann werden sofern ich noch auf dem aktuellsten Stand bin nur die UTXOs behalten und alle Daten der genutzen TXOs werden verworfen und es werden meines Wissens auch keinerlei kleinen Restdaten bezüglich der „verbrauchten“ TXOs behalten, aber das müsste man im Quellcode dann nachschauen. Als die Blockchain ungefähr 250GB groß war konnte man sie so auf ~5GB reduzieren, was aktuell dabei rauskommen würde müsste man selber im Testversuch rausfinden oder es googlen.
Es ist nicht das Vorgehen welches du beschrieben hast, aber es ist sagen wir mal in derselben Familie der Ideen und auch seit Version 0.10 (oder doch erst 0.11?) implementiert und von jedem nutzbar, deswegen behauptet auch nie jemand, dass der Speicherplatz ein Bottleneck für die Bitcoin Blockchain ist.
Das wäre etwas zu wenig.
Aber ja und SPV macht dieser Theorie auch sicherlich einen Strich durch die Rechnung.
Trotzdem kommen mit dem Erhöhen der Blöckgröße einige Risiken. Das ist sicherlich keine Lösung für das Skalierungsproblem. Vielleicht kurzfristig, aber ganz sicher nicht langfristig. Nja, das Thema ist mittlerweile mehr als 10 Jahre alt und das werden wir hier sicherlich nicht lösen.
Ich habe da jetzt 2 Punkte zusammengeworfen prune=1 ist das aktivieren von manuellem pruning über RPCs, alles ab prune=550 gibt den verfügbaren Speicher für die Node an.
So wie ich das oben beschrieben habe ist es falsch. Mit prune=1 in der config kannst du über RPCs selbstständig alte Daten löschen, also zu wenig ist es nicht, im Gegensatz, es wäre eher zu viel, weil alle Daten bleiben. Wenn man das löschen automatisch übernommen haben will, dann muss man hinter prune= die maximale Größe in MiB angeben, die man der Node zur Verfügung stellt.
Könnte schwören, dass prune=1 einfach nur pruning bei einem alten release aktiviert hat und nur das UTXO Set behielt, entweder ich bin ganz bekloppt und es war prune=1 immer gleich manuelles RPC pruning aktivieren oder das ist seit einem der letzten release passiert. Werde mir mal morgen die 0.12. bis 0.15. release alle mit prune=1 starten und schauen ob ich in die Irrenanstalt gehöre.
Große Blöcke haben sehr viele Nachteile, aber sie führen nicht wegen dem Speicherplatz zu Zentralisierung oder bilden deswegen ein Problem. Wer, der Ahnung hat bzw. sich mal damit beschäftigt hat, behauptet sowas aktuell in dem Space?
Edit:
Zusammenfassung
To summarize autoprune: this adds a -prune=N option to bitcoind, which if set to N>0 will enable autoprune. When autopruning is enabled, block and undo files will be deleted to try to keep total space used by those files to below the prune target (N, in MB) specified by the user, subject to some constraints:
The last 288 blocks on the main chain are always kept (MIN_BLOCKS_TO_KEEP),
N must be at least 550MB (chosen as a value for the target that could reasonably be met, with some assumptions about block sizes, orphan rates, etc; see comment in main.h),
No blocks are pruned until chainActive is at least 100,000 blocks long (on mainnet; defined separately for mainnet, testnet, and regtest in chainparams as nAutopruneAfterHeight).
Pruning kam in der Version 0.11.0 zum Einsatz und hat wohl anfangs nur die Optionen prune=0, aus und prune>=550 gehabt. Gar keine Funktion für prune=1.
Zusätzlich definiert der Wert bei prune nur wie viel Speicherplatz zusätzlich zu dem UTXO Set und dem Block Index noch der Node zur Verfügung gestellt wird und es werden mindestens die letzten 288 Blöcke ganz behalten. Habe in den Folgereleases nichts gefunden was diese Ursprungsparameter geändert hätte.
Was momentan einem ca. 3,75GB UTXO Set + dem Minimum an 0,55GB als pruning Untergrenze bedeuten würde + halt die restlichen Nebendaten die halt nicht prunebar sind. Was weiterhin bei ~5-7GB in Summe liegen dürfte.
Now there is auto-prune and manual-prune. The user enables manual pruning on the command line with prune=1 and then uses an RPC command to prune: „pruneblockchain X“ to prune up to height X.
Manuelles Pruning kam erst mit dem Release 0.14.0 und somit die erste mögliche Nutzung von prune=1 in der config. Kann mir nicht erklären wieso ich im Kopf hätte, dass mit prune=1 eine automatische Limitierung auf das UTXO Set alleine beinhaltet wäre. Eventuell hab ich damals halt prune=550 drin gehabt und mir blieb einfach im Kopf, dass es nun mit prune=1 eine neue Option gibt und ich bildete mir ein, dass das Verharren auf ~5GB wäre, weil ich prune=1 in der Config habe, obwohl es nie der Fall war.
Nun sei es drum, ich gehör eindeutig in die Irrenanstalt , aber ja, man kann auch aktuell eine Full Node mit sicherlich weniger als 15GB in Summe betreiben. Speicherplatz ist kein Problem welches zu Zentralisierung führt.
Als Miner könnte man mit unendlich großen Blöcken einen Wettbewerbsvorteil haben. Klar nicht bei 8, 16 oder 32MB Blöcken, aber bei 128MB+ Blöcken. Stichwort Übertragungsgeschwindigkeit zu den anderen Nodes. Während ich schon längst am neuen Block mine, suchen die anderen noch immer nach dem alten weil meiner am anderen Ende der Welt noch nicht angekommen ist.
Über pruning wird wirklich NIE gesprochen. Ich wusste bereits davon, wusste auch wie es funktioniert aber so wirklich auf dem Schirm hatte ich es nicht. In Kombination mit einer Lightning Node ist das Ganze ja auch kein Problem. Muss auch sagen, dass ich es nie getestet habe aber ich war mir bewusst wie man es einsetzt. Nicht einmal die Bcash Seiten erheben dieses Argument. In dieser Debatte wird einzig und allein immer nur von SPVs gesprochen. Woran könnte das liegen? Bringt pruning andere Nachteile mit sich? Wie lange dauert es so eine „Lite“ Full Node aufzusetzen? Ist das auch wirklich schneller?
Der einzige Punkt der mir einfallen könnte ist, dass man halt nicht mehr „zurück“ kann. Will ich dann die doch die gesamte Blockchain haben muss ich alles von vorne neu downloaden/synchronisieren.
Wie Dash Jr. auch im verlinkten Artikel schreibt liegt es bei einer z.B. 8MB Blockgröße nicht nur am mangelnden Speicherplatz:
However, at the same time, the current rate of blockchain growth is demonstratably too high for many users: full node count and percentage continue to drop (with the most-cited reason being blockchain-size related); miners are de-facto skipping validity checking of blocks before mining on top of them; and the total cost to sync a new node for the first time is growing significantly faster than technology improvements to reduce such costs. It is a regular occurrence to see new users complain about the time to setup a node, and established members of the community recommending downgrading to non-full wallet software, which results in the new user gaining bitcoin as a currency, but not the security of Bitcoin itself, and compromises the integrity of the network as a whole by widespread usage.
Das liegt aber nicht am Speicherplatz.
Diese Debatte ist schon so alt und es gibt noch immer diese Fehlinformationen.
128MB an Daten speichern ist nicht das Problem. Das Problem ist wie du sagst die Übertragung der Daten in einer vernünftigen Zeit (nicht jeder genießt eine 40+ Mbit Leitung auf der Welt) und dass diese erhaltenen Daten ja auch zusätzlich verarbeitet werden müssen (Signaturen überprüft werden usw.) und es ab einer gewissen Größe an MB für viele Haushalt-PC/Server nicht mehr möglich sein wird mit der Geschwindigkeit der Blockentstehungen mitzugehen und für sie das Verfizieren der Blöcke im Schnitt länger dauern wird als 10 Min.
Weiters kommt, dass bei größeren Blöcken beim IBD (erst Download der ganzen Historie beim Erstlauf der Node) das aufholen auf den aktuellen Stand ewig dauern wird. Ein RPi3 z.B. (ohne CPU overclocken) schafft es meines Wissens nach nur so weit die ersten kleinen Blöcke so schnell abzuarbeiten, dass er auf die aktuelle Blockhöhe aufholt, bis der 280k Blöcke hinten ist und dann tut sich da vom Aufholen her nicht mehr viel, da holt er vielleicht alle paar Tage 10-15 Blöcke oder so auf. Da ist die SSD mit 500GB nicht das Problem. Das schreiben der Daten und das aufbewahren von den Daten ist kein Bottleneck. Sofern jeder in Zukunft 5Tbit Leitungen haben sollte und unsere Prozessoren 70GHz raushauen, aber die Festplatten/Speichermedien sich gar nicht entwickeln, dann könnte natürlich in Zukunft das Speichermedium zum Bottleneck werden, aber das ist es momentan nicht. Ein Raspiblitz (RPi4 mit 4GB RAM) braucht derweil auch über 1 Woche um die Chain zu verarbeiten und das obwohl man mit Bitcoin Core da eh etwas schummeln (assumevalid) um es angenehmer von der UX zu machen.
Das Problem bei solchen Fehlinformationen ist eben, dass dann ein bedeutender Teil an Anhängern zu dem Fork von Bcash mitwandert, weil solche Aussagen eindeutig falsch sind und man sich verarscht fühlt, wenn man tausend mal dieselben „Fakten“ präsentiert kriegt, obwohl sie nicht stimmen.
Wobei angemerkt werden muss, dass viele nicht zu „retten“ waren und sowieso von der Ideologie sich dann abgespalten hätten, aber ich auch welche kenne die sich einfach für dumm verkauft vorgekommen sind.
Luke wurde mehrfach auf Twitter (auch 2018/19 bei seinen nächsten Versuchen die Blocksize zu verringern) darauf hingewiesen, dass er in dem BIP da nicht storage hinschreiben sollte, weil es kein Problem darstellt, aber er blockt ja jeden sofort auf Twitter, der ihm widerspricht oder irgendwas gegen den Katholizismus sagt. Der Typ ist einfach verrückt.
Seine Bedenken wegen der Internetleitung und der Prozessorleistung der einfachen Nutzer sind mehr als berechtigt, aber die Bedenken, die er hatte, dass die Festplatten nicht mit den ganzen Schreibzyklen mitkommen würden hat er auf Twitter mehrmals „falsifiziert“ bekommen, jeder Laptop der letzten 5 Jahre hat fast immer mindestens eine 128GB SSD verbaut, sofern die Schreibgeschwindigkeit wirklich ein Problem sein sollte um auf dem aktuellen Stand der Chain zu bleiben.
Kann dir leider keine Threads raussuchen, ich sehe nix auf seinem Profil, weil ich von ihm blockiert wurde. ^^
Die Bcasher haben ja (der Großteil von ihnen) nie das Interesse daran gehabt zu argumentieren, dass die Homenodes eh möglich wären mit einem Blocksizeincrease. Ihre Ansicht ist, dass man als einfacher Nutzer keine laufen lassen muss, da bringt es auch nichts für sie zu argumentieren, dass Speicherplatz damit behoben wäre, dass man eine Fullnode im Prunemode laufen lässt. Die Probleme mit der Internetanbindung und der Prozessorleistung fallen ja dadurch nicht weg. Sind in deren Augen aber auch kein Problem, wozu muss schließlich ein normaler Nutzer eine Node laufen lassen?
Also diese Frage kriegt man von ihnen gestellt, deswegen auch immer das verweisen auf SPVs.
Der größte Nachtteil beim pruning ist, dass man einfach limitiert ist in den Services die man auf der Node aufbauen kann. Am einfachsten erklärt ist es am Beispiel Explorer. Wenn du deinen eigenen Explorer laufen lassen willst, dann kann der nicht alte Daten löschen, wenn er diese Anzeigen können soll. Beispielsweise gibt es da diesen BTC-RPC-Explorer, den auch der Raspiblitz und Dojo von Samourai als Services in ihr Produkt eingebunden haben, wenn man selber einen Explorer hosten will.
Weiters gingen zum Beispiel die Lightning Implementierungen nicht in prunemode. Soweit ich weiß hat c-lightning als erste Implementierung dann irgendwann es geschafft auch im prunemode die LN Node laufen zu lassen, weiß aber nicht ob die anderen 2 großen da nun nachgezogen sind oder wie der Status ist.
Ich will nicht sagen, dass das Speichermedium überhaupt keinen Einfluss auf die Performance ausübt, weil jede Komponente immer optimiert werden kann und optimiert werden wird und sofern jemand SSDs verwendet, dann wird er sicher besser damit fahren als jemand der HDDs verwendet, aber es ist nicht der Speicherplatz/bedarf das Problem welches Leute daran hindert, dass sie eine Node laufen lassen. Es sind primär deren Internetanbieter und deren CPU, die für die Leute ein Bottleneck darstellen. Ein jeder von uns holt sich selbst über USB2.0 Datenmengen in einer Stunde die größer sind als 2 Wochen an Blöcken.
Ich habe nichts dagegen, wenn man argumentieren will, dass die Festplatten in Zukunft kein Upside mehr haben und Researchpaper XYZ schlechte Entwicklungen vorhersagen im Vergleich zu Breitbandentwicklung und CPU-Entwicklung, aber es ist aktuell nicht wahr, dass das ein Problem darstellt oder zu Zentralisierung führt und genauso etwas was heute von Roman gesagt wurde, dass Millionen (hat er mehrere Millionen oder Millionen Menschen gesagt?) über den Quellcode bei einer Änderung/einem Release schauen. Das stimmt nicht und die Leute fühlen sich wie gesagt für dumm verkauft, wenn man ihnen sowas erzählt und sie später merken, dass es bullshit ist.
Was die Blockgröße betrifft stimme ich dir in deinem ersten Absatz vollkommen zu.
Die richtige Lösung um seine Ideologie (größere Blöcke) zu verfolgen ist und war aber ganz sicher nicht Bcash zu verfolgen. Wenn man sich für Bitcoin interessiert hat man deutlich mehr Grundsätze als Skalierungsprobleme und die Blocksize. Jetzt mal abgesehen davon, dass größere Blöcke keine langfristige Lösung bieten: Was bringt es wenn ich dann zwar meine großen Blöcke habe und ich mich aber trotzdem einem zentralisierten, irreführenden und betrügerischen System hingebe?
Würde mich bei so einigen Aktionen der Roger Ver/Jihan Seite eher für dumm verkauft vorkommen.
Macht Sinn aber diese Sichtweise und Einstellung zu Full Nodes versteh ich einfach nicht. Naja…
Ich weiß nicht wo er das gesagt hat, aber das würde ich nicht so eng sehen. In Konversationen tendiert man gerne dazu zu übertreiben und ich denke, dass die Zuhörer das auch wissen. Klar, korrekt wäre gewesen hunderte reviewen die Pull Requests und Commits. Umso wichtiger diese „Quellcodes“ sind und bei schweren Eingriffen ins Protokoll ist die Anzahl an Reviewern natürlich deutlich höher. Das nicht Millionen/mehrere Millionen Menschen sich täglich hinsetzen um PRs zu reviewen sollte jedem klar sein. Oder? Wir haben ja nichtmal soviele Bitcoin Nutzer/Besitzer.
Wenn man das löschen automatisch übernommen haben will, dann muss man hinter prune= die maximale Größe in MiB angeben, die man der Node zur Verfügung stellt.
