Re: Der Aktuelle Kursverlauf blockgrösse

[MoinCoin]

@CB
Naja das ist ja nicht was ich unter Segwit+2MB verstanden hatte.
Alle Clients von Core werden das Segwit aus dem Vorschlag nicht unterstützen.

Und der Hard Fork kommt mir einfach viel zu früh - 12 Monate hätte ich für angemessen gehalten.

Dezentral - so ungefähr wie aktuell

[1714972572]

1714972572

[Bergmann_Christoph]

Natürlich bedeutet dezentral mindestens, dass ich einen Knoten laufen lassen kann. Ist wie bei EMail, das ist auch dezentral. Kann dagegen nur WhatsApp einen Server laufen lassen, dann ist das System zentral. Bestimmt ein Oligopol von Minern die weitere Entwicklung, dann ist das System ebenfalls zentral.

Für den Erfolg ist ein dezentrale Struktur nicht wichtig, das stimmt. Dafür gibt es aber bereits Lösungen, unter anderem Paypal. Niemand benötigt Bitcoin um ein mit Paypal vergleichbares System umzusetzen.

Schon klar, aber wenn wir eine dezentrale Struktur haben, aber keinen Erfolg, ist der Welt auch nicht so richtig geholfen. PayPal wird sich freuen

Das "Ich" ist etwas wage. Du? Ich? Jemand in Japan? Jemand in Ungarn? In Nigeria?

Angesichts des Preisanstiegs und des Gewinns, den ein Early Adopter wie du gemacht hast, finde ich kann man auch für einen full Node mehr als 200 Euro bezahlen. Ein Pruning Node mit Traffic-Limit wird jeder noch sehr lange fahren können.

[Bergmann_Christoph]

@CB
Naja das ist ja nicht was ich unter Segwit+2MB verstanden hatte.
Alle Clients von Core werden das Segwit aus dem Vorschlag nicht unterstützen.

Und der Hard Fork kommt mir einfach viel zu früh - 12 Monate hätte ich für angemessen gehalten.

Dezentral - so ungefähr wie aktuell

D.h. du hast lieber kein SegWit als diesen Kompromiss?

[MoinCoin]

Ich warte da jetzt erstmal ab, was da passiert.
Mir ist noch nicht klar, ob das wirklich durchgeht, ob das wirklich so passiert ist und was der wirkliche Inhalt des Dokuments ist.

Da es ein Hard Fork ist werden die Coins ja sowieso verdoppelt, also kann ich mir das später immer noch überlegen.

Edit:
Ich hatte ja schon vorher geschrieben.
Ich bin zufriden mit Segwit in einem Jahr über BIP149
Solange eben Rootstock

[mezzomix]

Schon klar, aber wenn wir eine dezentrale Struktur haben, aber keinen Erfolg, ist der Welt auch nicht so richtig geholfen. PayPal wird sich freuen

Ich bin mit diesem "kein Erfolg" recht zufrieden. Von mir aus muss Bitcoin nicht die Weltherrschaft erringen - es wäre mir sogar lieber, wenn es das nicht macht.

Paypal freut sich unabhängig von Bitcoin sowieso. Solange deren Kunden mitspielen und ich der Nutzung ohne massive Probleme entgehen kann, ist das aktzeptabel.

Das "Ich" ist etwas wage. Du? Ich? Jemand in Japan? Jemand in Ungarn? In Nigeria?

Angesichts des Preisanstiegs und des Gewinns, den ein Early Adopter wie du gemacht hast, finde ich kann man auch für einen full Node mehr als 200 Euro bezahlen. Ein Pruning Node mit Traffic-Limit wird jeder noch sehr lange fahren können.

Das ich ist nicht vage, es bedeutet genau ich persönlich kann einen Full Node laufen lassen. Ich gebe aber nicht sinnlos viel Geld dafür aus, nur weil ich es könnte. Wenn es mir nicht mehr sinnvoll erscheint, dann steige ich ganz einfach aus. Und da die Alternativen noch wesentlich schlechter sind, wäre damit das Thema freies Geld für mich komplett erledigt bzw. ein gescheitertes Experiment.

Das Problem mit den Leuten, die nach einem Führer lechzen ist, dass sie mich einfach nicht verstehen können. Das ist so und ich fürchte das wird sich auch nie ändern.

[Bergmann_Christoph]

Ich warte da jetzt erstmal ab, was da passiert.
Mir ist noch nicht klar, ob das wirklich durchgeht, ob das wirklich so passiert ist und was der wirkliche Inhalt des Dokuments ist.

Da es ein Hard Fork ist werden die Coins ja sowieso verdoppelt, also kann ich mir das später immer noch überlegen.

Edit:
Ich hatte ja schon vorher geschrieben.
Ich bin zufriden mit Segwit in einem Jahr über BIP149
Solange eben Rootstock

Ok, ein Jahr? Echt?

Wenn du mit BIP149 zufrieden bist, wie findest du dann das hier? https://github.com/bitcoin/bitcoin/pull/10428

[Bergmann_Christoph]

Schon klar, aber wenn wir eine dezentrale Struktur haben, aber keinen Erfolg, ist der Welt auch nicht so richtig geholfen. PayPal wird sich freuen

Ich bin mit diesem "kein Erfolg" recht zufrieden. Von mir aus muss Bitcoin nicht die Weltherrschaft erringen - es wäre mir sogar lieber, wenn es das nicht macht.

Paypal freut sich unabhängig von Bitcoin sowieso. Solange deren Kunden mitspielen und ich der Nutzung ohne massive Probleme entgehen kann, ist das aktzeptabel.

Das "Ich" ist etwas wage. Du? Ich? Jemand in Japan? Jemand in Ungarn? In Nigeria?

Angesichts des Preisanstiegs und des Gewinns, den ein Early Adopter wie du gemacht hast, finde ich kann man auch für einen full Node mehr als 200 Euro bezahlen. Ein Pruning Node mit Traffic-Limit wird jeder noch sehr lange fahren können.

Das ich ist nicht vage, es bedeutet genau ich persönlich kann einen Full Node laufen lassen. Ich gebe aber nicht sinnlos viel Geld dafür aus, nur weil ich es könnte. Wenn es mir nicht mehr sinnvoll erscheint, dann steige ich ganz einfach aus. Und da die Alternativen noch wesentlich schlechter sind, wäre damit das Thema freies Geld für mich komplett erledigt bzw. ein gescheitertes Experiment.

Das Problem mit den Leuten, die nach einem Führer lechzen ist, dass sie mich einfach nicht verstehen können. Das ist so und ich fürchte das wird sich auch nie ändern.

Verstehe ich das richtig: Das Thema freies Geld ist für dich komplett erledigt, wenn du einen Betrag, der für dich zwar kein Problem ist, aber den du für nicht sinnvoll hältst, dafür ausgeben müsstest, um einen Full Node zu betreiben?

Und hei - warum lechze ich deswegen nach einem Führer? Was hat das denn damit zu tun?

[MoinCoin]

Ok, ein Jahr? Echt?

Wenn du mit BIP149 zufrieden bist, wie findest du dann das hier? https://github.com/bitcoin/bitcoin/pull/10428

Ich hab ja schon ein paar mal zu BIP148 geschrieben.
Ich bevorzuge aktuell BIP149

Ohne Unterstützung von Minern wird es die Chain nie geben.
Ohne breite Unterstützung von Exchanges wird man schwer ökonomischen Druck ausüben können.

Da es optional ist sehe ich nicht das große Problem darin.

Um mal aufzulisten, was ich für sinnvoll halte und unterstützen würde (absteigende Präferenz, aber nicht untereinander exclusiv):

• Segwit über BIP149
• Extension Blocks, kompatibel zu Segwit BIP141
• Rootstock RSK
• Segwit + 2 MB HF in ~12 Monaten, unter der Vorraussetzung, dass Segwit kompatibel zu Bitcoin Core BIP141 ist, sonst hat man ja kaum einen Vorteil durch Segwit
• BIP148 mit >50% Miner Unterstützung
• Status quo

Alles andere überzeugt mich derzeit nicht

[mezzomix]

Verstehe ich das richtig: Das Thema freies Geld ist für dich komplett erledigt, wenn du einen Betrag, der für dich zwar kein Problem ist, aber den du für nicht sinnvoll hältst, dafür ausgeben müsstest, um einen Full Node zu betreiben?

Richtig. Denn wenn ich nicht mehr sinnvoll ein Full-Node betreiben kann, dann lässt sich leicht extrapolieren, dass es auch für alle anderen eher noch schwieriger wird. 5 Miner und 10 Knoten hat nichts mehr mit freiem Geld zu tun.

Und hei - warum lechze ich deswegen nach einem Führer? Was hat das denn damit zu tun?

Weil Du Lösungen immer nur bei ausgewählten Führern suchst. DIe Nutzer haben in dem von Dir transportierten System- und Weltbild nichts zu suchen, sie sind rein passiv. Teilweise schreibst Du das direkt, ansonsten steht es zwischen den Zeilen. Auch die folgende Frage habe ich als Kritik verstanden, denn eine positive Einstellung dazu hättest Du anders transportieren müssen:

Wenn du mit BIP149 zufrieden bist, wie findest du dann das hier? https://github.com/bitcoin/bitcoin/pull/10428

Ich war zwar nicht gefragt, finde das aber gut:

Disabled by default, this optional parameter allows a user to choose bip148 enforcement.

Klar, passt nicht zu einem Führerkult - aber das Thema hatten wir ja schon.

[Bergmann_Christoph]

Euch ist schon klar, dass die ganze Sache mit Bitcoin Unlimited darum ging, dass der User selbst entscheiden konnte, wie groß die Blöcke sind, die er akzeptiert? Warum war das ein Mega-Problem, weil es zum Chain-Split kommen kann - während es ok ist, dass der User per bip148 sich aussucht, ob er die Chain splittet?

Verstehe ich echt nicht.

[MoinCoin]

Das hatte ich am Anfang auch gedacht zu BU.

Aber je mehr ich darüber nachgedacht habe, desto mehr bin ich zu der Erkenntnis gekommen, dass es für die Nutzer einfach nicht funktioniert.
Die Koordination unter Nutzern würde so schwierig sein (angenommen BU ist der dominierende Client), dass man als einzelner Nutzer da zwar irgendwas einstellen kann, das tatsächlich aber keine Auswirkung hat, sondern ausschließlich die Miner dann die Aufgabe übernehmen die Blockgröße festzulegen.

Edit:
zum Chain Split: BIP148 in Core macht es nur leichter den RPC Call invalidateblock zu automatisieren.
Bei BU hat es meiner Meinung nach sowieso keine Bedeutung, was man als EB einstellt, abgesehen man nimmt für EB=1 und AD=inf, das was da von Core Trolls als Chain Split Risiko angeprangert wurde existiert meiner Meinung nach nicht, weil das System so nicht mehr funktioniert, wenn man die Macht an die Miner abgegeben hat.

[Bergmann_Christoph]

Das hatte ich am Anfang auch gedacht zu BU.

Aber je mehr ich darüber nachgedacht habe, desto mehr bin ich zu der Erkenntnis gekommen, dass es für die Nutzer einfach nicht funktioniert.
Die Koordination unter Nutzern würde so schwierig sein (angenommen BU ist der dominierende Client), dass man als einzelner Nutzer da zwar irgendwas einstellen kann, das tatsächlich aber keine Auswirkung hat, sondern ausschließlich die Miner dann die Aufgabe übernehmen die Blockgröße festzulegen.

Je nach AD hat die EB bei BU dieselbe Funktion wie UASF: sie ignoriert Blöcke, die eine bestimmte Regel verletzen. Der Unterschied ist halt, dass man bei BU noch die Option hat, im Zweifel auch der Mehrheit der Hashrate zu folgen.

Edit: Hast du eigentlich meine Frage beantwortet, was mit der UASF-Chain passiert, wenn die Legacy-Chain einen SegWit-Block anhängt?

[MoinCoin]

Je nach AD hat die EB bei BU dieselbe Funktion wie UASF: sie ignoriert Blöcke, die eine bestimmte Regel verletzen. Der Unterschied ist halt, dass man bei BU noch die Option hat, im Zweifel auch der Mehrheit der Hashrate zu folgen.

Siehe mein Edit oben - technisch stimmt das zwar, aber ökonomisch und politisch kann ich mir das nicht ansatzweise vorstellen, dass das ähnlich funktionieren würde, da keine ausreichende Koordinierung stattfinden würde.

Edit:
Wenn die Legacy Chains Segwit Blöcke anhängt, dann kann ein BIP148 Client das nie sehen, weil da nach seinen Regeln ein ungültiger Block dazwischen ist - und das wird sich ja auch nie ändern.

[Bergmann_Christoph]

Na klasse, jetzt kommunizieren wir mit unseren Edits:

Ich:

Edit: Hast du eigentlich meine Frage beantwortet, was mit der UASF-Chain passiert, wenn die Legacy-Chain einen SegWit-Block anhängt?

-- würde ich wirklich gerne wissen.

Bei BU hat es meiner Meinung nach sowieso keine Bedeutung, was man als EB einstellt, abgesehen man nimmt für EB=1 und AD=inf, das was da von Core Trolls als Chain Split Risiko angeprangert wurde existiert meiner Meinung nach nicht, weil das System so nicht mehr funktioniert, wenn man die Macht an die Miner abgegeben hat.

Warum geben die Nodes ihre Macht an die Miner ab, wenn sie AD=inf (pseudo-inf) einstellen können? Die Nodes können, wie jetzt auch, Blöcke ignorieren, die eine Regel verletzen.

Edit: Danke! D.h. alle Blöcke ab dem 1. August, die nicht SegWit signalisieren, sind ungültig. Hilft mir sehr weiter!

[MoinCoin]

Danke! D.h. alle Blöcke ab dem 1. August, die nicht SegWit signalisieren, sind ungültig. Hilft mir sehr weiter!

Genau die Kette von einem BIP148 Client bleibt dann in dem Fall stehen, wenn alle Miner weiter auf der Legacy Chain arbeiten.
Der Witz ist ja auch, dass für den BIP148 Client die Zeit stehen bleibt, denn es gilt nicht die aktuelle Systemzeit, sondern die Median Zeit aus den letzten empfangenen Blöcken.

Hier der BIP148 patch:

src/validation.cpp
 @@ -1851,6 +1851,22 @@ bool ConnectBlock(const CBlock& block, CValidationState& state, CBlockIndex* pin
         flags |= SCRIPT_VERIFY_NULLDUMMY;
     }
 
+    if (IsArgSet("-bip148")) {
+        // BIP148 mandatory segwit signalling.
+        int64_t nMedianTimePast = pindex->GetMedianTimePast();
+        if ( (nMedianTimePast >= 1501545600) &&  // Tue 01 Aug 2017 00:00:00 UTC
+                (nMedianTimePast <= 1510704000) &&  // Wed 15 Nov 2017 00:00:00 UTC

[MoinCoin]

Warum geben die Nodes ihre Macht an die Miner ab, wenn sie AD=inf (pseudo-inf) einstellen können? Die Nodes können, wie jetzt auch, Blöcke ignorieren, die eine Regel verletzen.

So wie ich das sehe, sind die Miner, welche für BU signalisieren überwiegend der Meinung, dass Sie festlegen sollten, was die richtige Blockgröße ist.

Ein Kriterium wird sicherlich sein, was ande Nodes als AD setzen.
Da das aber leicht ein Sybill-Angriff darauf erfolgen kann taugt das wohl kaum.

Das heißt es wird über irgendwelche Backroom-Deals festgelegt, welche Exchange oder Dienstleister welche Blockgröße für richtig hält.

Außerdem gehe ich sowieso davon aus, dass in einem EC Szenario die allermeisten Knoten auf SPV wechseln werden, da kann man dann sowieso nichts mehr einstellen.

Niemand wird in einem EC Szenario als normaler Nutzer genügend andere Nutzer finden können um ökonomischen Druck auf die Miner auszuüben.

[mezzomix]

Keine Ahnung, ob der Unmut der Nutzer langsam Folgen zeigt oder ob das wieder nur Taktik ist:
https://www.btc-echo.de/bitcoin-miner-einigen-sich-auf-segwit-aktivierung/

Sollte sich tatsächlich etwas tun, dann fragt man sich, warum Jihan Wu überhaupt das BU Drama vom Zaun brechen musste. Die Nutzerreaktion und auch die technsichen "Erfolge" haben ja gezeigt, wie gut das alles durchdacht war.

[Limx Dev]

Keine Ahnung, ob der Unmut der Nutzer langsam Folgen zeigt oder ob das wieder nur Taktik ist:
https://www.btc-echo.de/bitcoin-miner-einigen-sich-auf-segwit-aktivierung/

Sollte sich tatsächlich etwas tun, dann fragt man sich, warum Jihan Wu überhaupt das BU Drama vom Zaun brechen musste. Die Nutzerreaktion und auch die technsichen "Erfolge" haben ja gezeigt, wie gut das alles durchdacht war.

Danke ETH das du es möglich gemacht hast.    

[Bergmann_Christoph]

Warum geben die Nodes ihre Macht an die Miner ab, wenn sie AD=inf (pseudo-inf) einstellen können? Die Nodes können, wie jetzt auch, Blöcke ignorieren, die eine Regel verletzen.

So wie ich das sehe, sind die Miner, welche für BU signalisieren überwiegend der Meinung, dass Sie festlegen sollten, was die richtige Blockgröße ist.

Ein Kriterium wird sicherlich sein, was ande Nodes als AD setzen.
Da das aber leicht ein Sybill-Angriff darauf erfolgen kann taugt das wohl kaum.

Das heißt es wird über irgendwelche Backroom-Deals festgelegt, welche Exchange oder Dienstleister welche Blockgröße für richtig hält.

Außerdem gehe ich sowieso davon aus, dass in einem EC Szenario die allermeisten Knoten auf SPV wechseln werden, da kann man dann sowieso nichts mehr einstellen.

Niemand wird in einem EC Szenario als normaler Nutzer genügend andere Nutzer finden können um ökonomischen Druck auf die Miner auszuüben.

Das heißt, dich stört, was du denkst, dass die Miner denken, während es ein Fakt ist, dass die Miner dich auch mit EC ebenso wenig wie heute dazu zwingen können, eine gewisse Blocksize zu akzeptieren?

Langfristig werden wir sowieso irgendwann bei SPV-Nodes landen, da es in ein, zwei Jahrzehnten so oder so zuviel Daten sein werden, um zu syncen. Verstehe aber nicht, warum EC daran etwas ändern soll.

Auch verstehe ich nicht, weshalb du erwartest, dass sich in einem UASF-Szenario die normalen Nutzer gut organisieren können, um Druck auf die Miner auszuüben, nicht aber in einem EC-Szenario.

Meiner Meinung nach wird hier gewaltig mit verschiedenen Maaßen gemessen, weil eben "SegWit" und weil "BU" und so weiter.

Edit: Ich habe an sich weder etwas gegen das eine wie das andere. Ich finde es nur sehr schräg, dass ChainSplit mit SegWit ok ist, aber mit BU ein No-Go.

[MoinCoin]

Das heißt, dich stört, was du denkst, dass die Miner denken, während es ein Fakt ist, dass die Miner dich auch mit EC ebenso wenig wie heute dazu zwingen können, eine gewisse Blocksize zu akzeptieren?

Naja - also was stört mich daran? Das ich als Nutzer kein Mitspracherecht mehr habe, außer eben die spezielle Blockchain nicht zu benutzen.
Die Miner handeln eben im Interesse der Miner. Manchmal stimmt das eben mit dem Interesse eines durchschnittlichen Nutzers zusammen (Segwit / LN) und manchmal eben nicht.
Miner sind meiner Ansicht nach keine Feinde, aber man sollte sie nicht einfach machen lassen, was sie wollen.

Langfristig werden wir sowieso irgendwann bei SPV-Nodes landen, da es in ein, zwei Jahrzehnten so oder so zuviel Daten sein werden, um zu syncen. Verstehe aber nicht, warum EC daran etwas ändern soll.

Das sehe ich anders - Im Szenario EC ist das sehr wahrscheinlich, aber mit kleineren Blöcken nicht notwendig.
Zum Beispiel kommen da ja noch die UTXO-Commitments, mit denen man dann rückwärts syncen könnte.
Mit Segwit+2MB, also effektiv irgendwo zwischen 5-6 MB irgendwann mal pro Block reicht so eine 4 TB Festplatte ja doch einige Jahre.

Zum anderen ist das finde ich wieder ein Argument für Extension Blocks.
Bcoin hat aktuell auch eine Deaktivierung vorgesehen.
Das heißt man kann nachdem der spezielle Extension Block deaktiviert wurde sämtliche Daten aus der Extension Blockchain wegschmeißen.
Optimaler Weise hat man natürlich bereits einen neuen Extension Block vorher eingeführt, der dann die Aufgabe von diesem übernimmt.

Auch verstehe ich nicht, weshalb du erwartest, dass sich in einem UASF-Szenario die normalen Nutzer gut organisieren können, um Druck auf die Miner auszuüben, nicht aber in einem EC-Szenario.

Meiner Meinung nach wird hier gewaltig mit verschiedenen Maaßen gemessen, weil eben "SegWit" und weil "BU" und so weiter.

Edit: Ich habe an sich weder etwas gegen das eine wie das andere. Ich finde es nur sehr schräg, dass ChainSplit mit SegWit ok ist, aber mit BU ein No-Go.

Ich sehe nicht, dass die Organisation im BIP148 UASF Szenario reibungslos laufen würde, sonst wäre es ja wohl kaum so kontrovers. Keiner weiß, ob das jetzt wirklich stattfindet, oder wie das tatsächlich abliefe.

Das BIP148 Szenario ist einfacher, das heißt entweder unterstütz man das oder eben nicht. Und wenn es dann scheitert, dann ist man nicht schlechter als der status quo.

Bei einem EC Szenario gibt es sehr viele Unterschiedliche Wahlmöglichkeiten. Das macht das ganze schon schwerer gemeinsam Druck aufzubauen. Und was passiert, wenn das eigene EB Setting überstimmt wurde? Dann muss man eben aufgeben und trotzdem den größeren Blöcken folgen und hat nicht mehr den Status quo.

Chain Splits sind immer unglücklich - ich finde das mit BU auch kein No-Go. Die Idee, die viele bei BU haben (z.B. Peter Rizun) und die Architektur (Split am Anfang der Diff Period) ist allerdings so gewählt, dass die Kette mit der geringeren Hashrate die maximalen Nachteile hat (Kapazität für Transaktionen/s) und wird wahrscheinlich deswegen oft als Angriff gesehen.

Außerdem geht hier die Aktion von den Minern aus, während BIP148 die Aktion von den Usern ausgeht, weswegen es wahrscheinlich bei einigen Usern beliebter ist, weil Ihnen hier eine stärkere Mitgestaltungsmöglichkeit geboten wird. Ein Miner sieht das vielleicht anders.
Es ist beides suboptimal.

Deswegen bin ich ja auch weiterhin nicht wirklich überzeugt von BIP148.