Harsh Wahrheit zum Luke Hardfork-Drama: Ich denke nicht, dass es etwas Falsches daran gibt, einen _alternativen_ Client zu entwickeln, der sich mit dem neuesten, schwersten Chaintip über ZK synchronisiert, selbst wenn das bedeutet, nicht alle Blockinhalte herunterzuladen... selbst wenn es ein zentrales Konsortium (Multisig) gibt, das die Kontrolle darüber hat, welche Teile der Kette durch ZK validiert werden und welche normal validiert werden. Selbst wenn das bedeutet, dass der _Referenzclient_ (Core) beim Synchronisieren der Kette stecken bleibt, wenn die EINZIGEN Daten, die im gesamten Netzwerk verfügbar sind, die sind, die mein alternativer Client hostet. Es WÄRE ein Problem, wenn der *Referenzclient* (oder der "große Mehrheit-Client") dies übernehmen würde... denn wenn die große Mehrheit des Netzwerks es ausführen würde, könnte das zu Chainsplit-Situationen führen. Es könnte auch ein Problem sein, wenn der alternative Client, der dies übernimmt, mit anderen Knoten im Netzwerk peer-to-peer kommuniziert und so tut, als ob sie die vollständigen Blockchain-Daten hätten, während sie in Wirklichkeit nicht über diese verfügen, und versuchten, nicht erkennbare ZK-Beweise an ahnungslose Peers anstelle von tatsächlichen Transaktionsdaten aus irgendeinem Grund zu liefern. Das wäre gleichbedeutend mit einem Eclipse-Angriff, aber wir haben keinen Grund zu glauben, dass jemand so etwas geplant hat oder planen würde. In Wirklichkeit würden solche Knoten (wenn ehrlich) wahrscheinlich einfach ein richtiges Service-Bit bewerben, das den Knoten, die synchronisieren (IBD), mitteilt, dass sie nicht alle Daten haben. So wie es auch die beschnittenen Core-Knoten im Netzwerk tun (Service-Bit: NODE_NETWORK_LIMITED == die Art und Weise, wie dein Knoten sagt: "Ich habe nicht die gesamte Blockhistorie... du musst dich mit jemand anderem verbinden, wenn du eine vollständige Synchronisation durchführen möchtest"). Ich bin kein Experte für die Synchronisationsmechanik von Core, aber ich glaube, dass Core-Knoten bereits Verbindungen priorisieren, die senden, dass sie die vollständigen Blockchain-Daten haben, und werden begrenzte Peers, die die vollständige Historie nicht bereitstellen können, ausstoßen/rotieren. Im Allgemeinen liegt es immer in der Verantwortung des Core-Clients, Peers zu rotieren und ehrliche Verbindungen im Netzwerk zu finden, um Widerstand gegen absichtlich feindliche sowie unbeabsichtigt feindliche Eclipse-Angriff-ähnliche Situationen im Netzwerk zu haben. 🔸🔸🔸🔸 Jetzt wird es kompliziert, wenn ich nicht nur diesen alternativen Client veröffentlicht/baut/geplant habe, sondern auch öffentlich Angst verbreitet habe, dass der Referenzclient ***den Tod von Bitcoin garantiert*** und ich auch rechtliche Wege erkundet habe, um Knoten oder Mining-Pools davon abzuhalten, Core auszuführen. Ich weiß nicht viel über diesen letzten (rechtlichen) Teil, also werde ich dazu nichts sagen. Jedenfalls ist das die Quintessenz, warum einige Leute sagen werden, dass das, was Luke plante, kein Zensur-Hardfork war (und nur ein Hardfork-Client in einer strengen technischen Definition, weil es unter unwahrscheinlichen Bedingungen einen Chainsplit auslösen kann), während andere den Angst verbreitenden/rechtlichen Kontext beobachten, der ein eher niederträchtiges Bild zeichnet. Ende.

und *welche* Teile normalerweise validiert werden... Tippfehler im ersten Absatz

Im Fall von Knots könnte das oben Genannte durchaus als eine optionale Funktion gedacht sein, nicht als etwas, das alle Knoten standardmäßig tun würden.