Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 81. (Read 185692 times)

Das wäre in diesem Umfeld aber nichts neues.

Das Problem daran ist, dass die Eingangsparameter für einen solchen Änderungsalgorithmus nur aus den Blöcken (sicher) abgeleitet werden kann. alle anderen Quellen für diese Parameter sind manipulierbar. Dies verschiebt aber die Kontrolle hin zum Mining, was gerade in der aktuellen Umgebung - gepägt durch wenige Pools in der Hand noch weniger Betreiber - unerwünscht ist.


Es gibt diverse Möglichkeiten, die das aktuelle System erlaubt. Wichtig ist, dass die Knotenbetreiber sich ihrer Möglichkeiten durch die Verifikation bewusst sind und nicht einfach blind dem Argument, sie hätten sowieso gegenüber einem Miner nichts zu melden, folgen.


Nicht das ich wüsste. Ein Teil der Idee stammt aus dem Bereich UTXO Commitment, bei dem ein Hash über das UTXO Set in den Blockheader aufgenommen wird. Diese erlaubt dann einen sicheren Bootstrap, basierend auf einem bereits aktzeptierten/verifizierten UTXO Set und erweitert das Pruning.


Wäre interessant, aber es ist relativ schwer, im aktuellen Nebel der Diskussion echte Details zu finden. Für die Prüfung des BU Code fehlt mir irgendwie der Antrieb.


Dann ist das eben so. Glücklicherweise muss ich der Herde zumindest hier nicht folgen.

Das wäre doch eindeutiger Diebstahl der Exchange?

Wenn du sie beispielsweise auf nem Exchange liegen hast, und der Betreiber sich denkt: "Ich bleibe offiziell bei Core und die gesplitten BU behalte ich für mich" dann bekommst du nur einen der beiden Coins. So wie ich das verstanden habe, macht man sicherheitshalber erst mal gar nichts (edit: ausser natürlich die Coins auf ner eigenen wallet lagern, sofern dies nicht bereits der Fall ist), bis man alles verstanden hat. Falls ich das falsch verstanden habe, bitte korrigieren.

So hatte ich es auch gedacht.
Bin nur verwirrt dass mezzo schreibt "im Vorfeld kümmern"

Herdentiere

Das bestreite ich ja nicht. Die Frage ist nur, wie wichtige, vom Protokoll vorgeschriebene, Parameter wie die maximale Blockgröße dann graduell verändert werden können. Wir haben ja heute dafür nur zwei Möglichkeiten:

- Hardfork: Vorteil: kann sämtliche Protokolländerungen betreffen. Nachteil: Riskant, kann einen Split zur Folge haben.
- Softfork: Vorteil: Kein Split, daher weniger riskant. Nachteil: Blockierbar durch Miningpools, nicht alle Parameter sind über einen SF änderbar.

Wird der Parameter "Blocksize" dagegen auf eine "automatisierte" Weise änderbar gemacht, brauchen wir weder Hard- noch Softforks. BU und BIP 100 bieten verschiedene Lösungen dafür: Das Protokoll stellt Regeln auf, nach denen die Nodes verschiedene Blockgrößen erlauben können. Bei BU weniger eingeschränkt als bei BIP 100.

Die andere Moglichkeit wäre natürlich UASF. Mal sehen, ob das am Ende kommt. Schlecht fände ich es nicht, kann aber mögliche (Fork-)Risiken nicht einschätzen.


Hört sich plausibel und interessant an. Gibt es dazu offizielle Diskussionen (letzter Satz deutet ja darauf hin) / ein BIP bzw. hat dieser Algorithmus einen Namen, damit ich mehr darüber lesen kann?


Trotzdem wäre es interessant zu wissen, ob bei BU irgendeine Zahl (z.B. 50% oder 75% der Blocks) als Anlass für den Fork vorgegeben ist.

Das gabs bei Ethereum ja auch. Als der Fork kam, konnte man aus den, ich nenne sie jetzt mal "Ur-Eth", einen Split durchführen. Man erhielt aus 100 Ur-ETH jeweils 100 ETHf und  100 ETC.

Nach den kürzlichen Ereignissen könnte man vermuten, dass der Anteil an Core Betreibern sogar deutlich über 83% liegt. 


Warum befürchtest Du das?

Aber ja, wenn die Leute sich entscheiden, dass ihnen ein BU-Coin mehr Wert ist als ein Bitcoin, dann würde genau das passieren. In diesem Fall müsstest Du im Vorfeld entsprechend handeln und vor allem sicherstellen, dass die Coins vor dem Fork unter Deiner alleinigen Kontrolle sind. Falls Dir dann die BU-Coins nicht zusagen, kannst Du (mit einigen Tricks und Kniffen) die BU Coins teuer verkaufen und die BTC behalten. Oder Du verkaufst alles und suchst Dir was anderes.

Vielen Dank
Ich verstehe es so, 83% Core-Nodes gegen 12% BU-Nodes.

Wenn aber die Poolbetreiber z.B. 80% BU-Blöcke schürfen und mit ihren eigenen 12% BU-Nodes ein eigenen "Altcoin" den Börsen anbieten,
würden die doch gern einen weiteren Altcoin anbieten.
Beispiel Finex bietet denn Bitcoin (Core) und BitcoinUnlimited an.

Jetzt sorge ich mich um den Werterhalt meiner alten Bitcoin(Core). Siehe ETH alt und neu.
Ich befürchte, das der Wert/Preis zur größten Hashpower fließt.

Nur soviel dazu: Es muss nicht zwingend alles automatisch vorgeplant ablaufen. Kontrollmöglichkeiten durch die Nutzer sind nicht generell etwas schlechtes!


Die Miner (wichtig: faktisch Pools) haben nur solange Macht, solange der Rest der Nutzer ihnen diese gibt. Es gibt durchaus Handlungsmöglichkeiten für die Nutzer, sich nicht von 3-4 Pools (evtl. kontrolliert von einem Betreiber!) blockieren zu lassen.


Die Zusammenschaöltung lässt sich nicht verhindern, ist aber massiv ineffizient, wenn in jeder Runde der vollständige Block und das UTXO Set benötigt wird. Ein Mining Knoten, der diese Informationen hat, ist sowieso nahezu vollständig funktionsfähig und hat keinen Grund mehr, sein Ergebnis bei einem Pool abzuliefern. Nebenbei erzeugt alleine die Übertragung des jeweils aktuellen Blocks einen massiven Overhead, sodass lokales Mining deutlich effizienter wird. Daneben lässt sich ein solcher Algorithmus nicht mehr auf einem einfachen ASIC umsetzen. Interessant, da der blockierende Poolbetreiber gleichzeitig der ASIC-Baron ist.


Das Problem der BUler ist, dass es keine feindliche Übernahme geben kann, solange das Netzwerk grösstenteils aus Nicht-BU Knoten besteht. Mit dem Versuch würden sie sich selbst aus dem Netz forken. Unter diesem Gesichtspunkt ist auch das lautstarke Auftreten und die Implikation einer Herrschaft der Poolbetreiber zu sehen. Statt dem Fork könnten sie mit dem selben Effekt auch einfach das Mining abschalten.

Bitte um Hilfe. Ich sehe meine Eigentumsverhältnisse gefährdet. Sehr ernst gemeine Frage.
Politische Formulierungen bitte nicht persönlich nehmen, soll dem Verständnis dienen.

Was ich als technischer Leihe sehen kann:

https://coin.dance/nodes
ca. 83% der Nodes sind Core, für mich versteht sich das als Bitcoin. Größtenteils userbase.
ca. 12% der Nodes sind BU, für mich nach Hardfork ein Altcoin. Zentral von BU-Block Zentrale?

https://coin.dance/blocks
Bitcoin (core) ca. 67% Blocks, Tendenz sinkend.
BU 32% Blocks, Tendenz steigend.

1. Frage
Ab wann ist eine die BU "feindliche Übernahme" geplant? Gibt es ein Termin oder ein Bockmenge in Prozent als Startschuss?

2. Frage
Was passiert mit meinen alten Bitcoin? Die können doch in beide Chains überwiesen werden. So dass ich dort verkaufen kann, wo der Preis höher ist?

Bitte um Hilfe.

Die Frage ist eben: Wenn man ein flexiblereres System oder Automatismen für Parameter wie die maximale Blockgröße einbauen möchte, um aufwändige Hard- und Softforks zu vermeiden - wer soll dann die Entscheidung treffen? Da fällt mir außer PoS und Minern nicht viel ein, alles andere ist manipulierbar.

Bei den heutigen Softforks haben die Miner bzw. Pools de facto ja durchaus Macht, wie man bei Segwit sieht. Die Idee hinter diesen Automatismus-Vorschlägen ist ja, diese "De-Facto-Macht" zumindest bei wichtigen Parametern anzuerkennen und zu regulieren. Etwa mit der 5%-Begrenzung des oben erwähnten BIP 100. Und dann könnte als Gegengewicht die Weiterleitungs-Blockade für normale Full-Nodes eingebaut werden.

Ansonsten sehe ich tatsächlich als Lösung nur, die Mininglandschaft so kleinteilig wie möglich zu "zerschlagen", wie du ja mit deiner Idee eines Algorithmus-Wechsels vorschlägst. Die Frage ist, ob sich eine Zentralisierung damit tatsächlich vermeiden lässt. Mir fehlt zwar etwas das Fachwissen dazu, aber egal bei welchem Algorithmus scheint es mir schwierig, zu verhindern, dass sich mehrere Rechner zu einem "Pool" zusammenschalten.

Der weithin bekannte Nutzer AnonyMint hat ja viele Beiträge zu dem Thema geschrieben, bei der er eine Möglichkeit eines nicht zur Zentralisierung tendierenden Proof-of-Work-Mining als sehr gering einschätzt (hauptsächlich allerdings im Altcoinforum). Er ist zwar ein bisschen ein Labersack (und lässt sich gerne von Trollen provozieren), hat aber imho schon das Wissen für einigermaßen fundierte Meinungen.

Eine andere Frage wäre, ob die derzeitige Mininglandschaft zentralisiert ist, weil die Pools selbst große Hardwarefarmen betreiben oder ob es tatsächlich noch viele unabhängige Miner gibt, die sich den Pools anschließen, weil sie sich höhere Effizienz versprechen. In Fall 1) wäre eine Lösung schwieriger, da ja dann die Zentralisierung schon bei den "Mining-Einheiten" beginnt und nicht nur die Pools daran schuld sind.

Die Richtung, mehr Transaktionen in einen Block zu bekommen halte ich für richtig. Das geht aber nicht über eine Abstimmung, basierend auf manipulierbaren Informationen.


Mit der aktuellen System-Architektur ist eine automatisierte Anpassung der Blockgrösse nicht möglich, ohne die Entscheidungsgewalt zu verändern. Daher halte ich nichts davon, Automatismen einzubauen die nahelegen, eine automatisierte Anpassung wäre möglich.


Davon halte ich nichts. Warum sollte der Anteil bestimmten Teilnehmern mehr Stimmrecht verleihen? Weshalb sollte jemand mit grösserem Anteil eher dafür qualifiziert sein, eine Entscheidung zu treffen?

Übrigens haben die Miner aktuell keine Macht in dieser Richtung. Es gibt schlicht kein Wahlsystem für Hard-Forks in der Architektur. Die Miner bzw. das ganze System lebt vom Handeln aller Teilnehmer. Der erste grobe Fehler ist, anzunehmen eine Rolle im System hätte hier eine höhere Entscheidungsgewalt. Saubere Änderungen erfordern einen Konsens oder - falls dies unmöglich ist - einen Split.

Hier gibts noch einen "neuen" Vorschlag: BIP 100 upgedated (von Jeff Garzik).

Wie beim von mir vorher vorgebrachten Vorschlag (der ja seinerseits auf BIP 100 basiert) voten die Miner gemeinsam eine Erhöhung oder Schrumpfung der Blockgröße, die aber dann von allen akzeptiert werden muss. Es gibt also nicht die Möglichkeit, dass im Netzwerk Votes für mehrere Blockgrößen gleichzeitig nebeneinander bestehen wie bei BU. Im Gegensatz zur ersten Variante von BIP 100 wurde die Erhöhung / Schrumpfung der Blockgröße auf 5% pro "Wahlperiode" begrenzt.

Zum BU-Bug: Der ist ein Hinweis darauf, dass das Development Team dahinter überfordert ist. Er ist aber kein Beweis, dass die Idee größerer Blöcke insgesamt falsch ist. BU halte ich nach wie vor für "zu gefährlich" als Scaling-Lösung, aber aus anderen Gründen (zu große Macht für Miner).


Kurzes Wort noch dazu:


Ich würde das vom Scaling-Vorschlag als solchen trennen, aber eigentlich könnte ich es mir sogar voll offiziell als Option im GUI vorstellen, bei der jeder die Softfork-Optionen "abstellen" kann, die er nicht möchte. Oder auch eine zu hohe Blockgröße (bei einem dynamischen Block-Voting-System wie bei BIP 100). Den Minern wird dadurch signalisiert, was ökonomisch sinnvoll für sie ist. Müsste man aber tatsächlich erst mal testen.

Eine andere Idee wäre ein Proof-of-Stake-basiertes Wahlsystem (ohne natürlich PoS als Konsensmechanismus für Blöcke einzuführen). In dem Fall hätten allerdings wohl derzeit die Exchanges die Macht, die im aktuellen Wahlsystem die Miner haben.