Einfluss von Bitcoin Core Entwicklern

Also mit Blick auf der Liste würde Anarchien am besten passen.
Letztlich ist das immer eine Definitionsfrage. Als Mathematiker ist aber die leere Menge immer auch eine Menge und demnach, als Analogie, wäre die herrschaftslose Herrschaft auch eine Herrschaftsform.

Was ist mit der Menge aller Mengen, die sich selbst nicht enthalten? Ist das eine Menge?

1 „Gefällt mir“

Wenn du der Barbier bist der alle Männer rasiert, nur nicht die, die sich selbst rasieren, dann schon. :wink:

2 „Gefällt mir“

Oder um beim Thema zu bleiben:
Du bist DER Herrscher der Herrschaftsform, in der jeder herrscht, außer den Herrschern.

2 „Gefällt mir“

Wenn du deinen eigenen Bitcoin, mit deinen eigenen Regeln machst, haben deine Bitcoin nur in jedem fremden Bitcoin Netzwerk keinen Wert. Aber wenn sich auch Andere deinen Regeln anschließen, Bildet ihr ein eigenes Netzwerk, mit eigenem Wert.

Außerdem, wenn ich ein Problem mit Traproot oder sogar Segwit habe, kann ich eine Node laufen lassen, die nur das originale Adressformat unterstützt. Dies wäre auch eine Art Regeländerung, ohne dass ich mich dem Netzwerk ausschließe oder an Wert verliere.

Vermutlich meinst du die Abstimmung bei Taproot und dass das demokratisch gewesen sei. Eine solche Abstimmung ist nicht Vorschrift. Man hat sich wohl dafür entschieden, um nicht das Netzwerk unnötig zu zerrütten, wie es wohl bei Segwit der Fall war.

Viel interessanter wäre, wenn weit weniger dafür gewesen wären. Hätte man dann Taproot nicht veröffentlicht? Höchstwahrscheinlich hätten die jenigen, welche dafür gewesen wären, es trotzdem veröffentlicht und nach und nach hätten sich dann immer mehr angeschlossen.

Wie würde man es dann nennen, Diktatur?

Daher schrieb ich auch „ein Zwang zu einem gewissen sozialen Konsens gewisser Größe“. Wenn ihr nur zu fünft sein solltet, dann ist der Coin quasi wertlos, weil kein anderer den annehmen würde. Tauschfunktion wäre nicht erfüllt.
An BCH und weiteren Forks, oder auch bei ETC hat man jedoch gesehen, dass auch eine kleinere Gruppe sich abspalten kann und ein gewisser Wert dahinter steckt. Da bin und bleibe ich bei dir. Die genaue Größe wird wohl erstmal keiner definieren oder herausfinden können, ab wann eine ausreichend große Netzwerkgröße erreicht ist.

Ich hätte vielleicht vorab klären sollen, dass ich mit Regeländerungen natürlich Hardforks meine. Da sind die Softforks natürlich nicht unmittelbar betroffen. Wobei Softforks ja auch kritisch betrachtet werden könnten, da hier Updates eingespielt werden können, die keine Abstimmung bedürfen. Und als Node-Betreiber die Mittel zur Ablehnung begrenzt sind.

Das ist ja auch der Grund, warum es Leute gibt, die Softforks stark ablehnen. Updates können nicht einfach durch Unterlassen eines Updates von dir abgelehnt werden. Vielmehr müsstest du dann aktiv werden und „Gegenfork“ umsetzen, falls das Update wirklich gegen deinen Willen verläuft.

Wie lief das nun eigentlich beim 0.24-Update? Für mich war das Update „plötzlich da“ und fertig. Gabs da Abstimmungen bezüglich der neuen Funktionen? Wie ist da die Vorgehensweise?

Kritiker behaupten, das Core-Team mache, was es wolle, und alle Nodes sind quasi dazu gezwungen, das Update spätestens zu installieren, wenn irgendwann mal ein hard-fork anstehen sollte. Also nach dem Hard-Fork seien ja alle bisherigen Soft-forks ja auch inbegriffen.

Diesen Punkt verstehe ich nicht.

Naja, nehmen wir an, es gibt jetzt weitere Versionen: 0.25, 0,26, 0,27. Sind ja lauter Soft-Forks.
Nun kommt ein Hard-Fork, nennen wir ihn 0.3. Und hier hätte ich geglaubt, dass dieser ja mehr oder weniger zwingend auf 0.27 basiert inkl. seinen nicht abwärtskompatiblen Neuerungen. Oder gibt es dann mehrere Hardforks, welche dann z.B. nur auf 0.26, und nur auf 0.25 ect. aufbauen? Wohl eher nicht, oder?

Neue Core Versionen sind nicht automatisch Soft Forks.

Eine Soft Fork schränkt die Konsensregeln ein und ist damit vorwärts kompatibel, während eine Hard Fork die Regeln ausweitet und damit nicht vorwärts kompatibel ist. Das ist alles.

Wenn ein Bitcoin Core Update z.B. nur eine neue Policy (wie mempoolfullrbf in 0.24) einführt oder einen Bug im Wallet Client behebt dann hat das nichts mit Konsensregeln bzw. einer Soft/Hard Fork zu tun.

Die letzte Soft Fork war das Taproot Update in 2021 (mit Core v21.1).

Also die Core Versionen kannst du aus dieser Diskussion erstmal raus lassen.

Wenn eine Hard Fork ansteht und du dich für eine Seite „entscheidest“, was soll das mit vorangegangenen Soft Forks zu tun haben?

Per Definition können dir diese Soft Forks doch egal sein, da sie deinen „alten“ Regeln eben nicht widersprechen. Es zwingt dich schließlich niemand die Funktionen einer Soft Fork, z.B. neue Taproot Adressen, zu nutzen.