Nein, der Artikel stellt die aktuelle Situation (vermutlich unabsichtlich) verzerrt dar.
Nach dem Artikel könnte man meinen, Gavin und Mike wären die einzigen, die einen hard fork zur Erhöhung der blocksize vorschlagen, das ist so schlicht falsch. BIP 100, "102" und "103" von Jeff und Pieter sehen ebenfalls einen hard fork vor.
Diese Art der Fehldarstellung ist leider sehr weit verbreitet. Die wenigsten selbst ernannten XT-Gegner scheinen sich im Klaren darüber zu sein, dass innerhalb des Core-Developer-Teams einen klaren Konsens darüber gab, einen hard fork in Kauf zu nehmen (das ist ohnehin "alternativlos"). Der Dissens bestand lediglich darüber, wie die Lösung danach aussehen sollte.
Um die verschiedenen Vorschläge mal kurz zu charakterisieren:
BIP 100 (Jeff Garzik)1.
hard fork2. dynamische Anpassung der blocksize
3. Beibehaltung der historischen Grenze von maximal 32 MB
4. wenn diese 32 MB erreicht werden und weiterhin Bedarf für größere blocks besteht ->
erneuter hard forkBIP 101 (Gavin Andresen)1.
hard fork2. 8 MB limit, Verdoppelung alle zwei Jahre
3. das würde z.B. bedeuten,
in ca. 10 Jahren würden
heutige DSL-Leitungen
nicht mehr ausreichen, um einen Full Node zu betreiben
4. Stellt man fest, dass man eine erneute Beschränkung der blocksize braucht, weil es zu groß wird, reicht ein ->
soft forkBIP "102" (Jeff Garzik)1.
hard fork2. 2 MB limit
3. reicht dieses 2 MB limit nicht mehr ->
erneuter hard fork(BIP "102" scheint mir eher eine Trotzreaktion gewesen zu sein anstatt ein konstruktiver Vorschlag)
BIP "103" (Pieter Wuille)1.
hard fork2. 4.4% Erhöhung der blocksize spätestens alle 100 Tage oder so, maximal 17.7% Erhöhung pro Jahr
3. Maximal ca. 2 GB im Jahr 2063
BIP "103" ist sehr konservativ und vorsichtig, aber es dürfte klar sein, dass damit auf absehbare Zeit eben auch nicht viel gewonnen ist.
Das bedeutet, sollte sich in den nächsten ein, zwei, drei Jahren herausstellen, dass tatsächlich ein bisschen mehr Transaktionen benötigt werden, führt uns auch BIP "103" zu einem ->
erneuten hard forkIch selber will mich hier gar nicht für BIP 101 aussprechen, ich halte eine Weiterentwicklung von Bitcoin unter XT auch für äußerst unglücklich.
Aber man muss BIP 101 schon zugute halten, dass es der einzige Vorschlag ist, der mit an Sicherheit grenzender Wahrscheinlichkeit einen erneuten hard fork in näherer Zukunft vermeidet.
Ein soft fork irgendwann ist kein Problem, sowas haben wir in der Geschichte von Bitcoin zigmal gemacht, ohne dass es große Diskussionen darum gegeben hätte.
Einen erneuten hard fork in der Zukunft quasi "per default" in den heutigen hard fork einzubauen, kann doch wirklich nicht ernsthaft in Erwägung gezogen werden. Gerade nach der Erfahrung, die wir jetzt machen.
Schließlich und endlich noch der Verweis auf die mittlerweile historische
Hardfork Wishlist. Diese sieht tatsächlich noch satoshis Hotfix einer simplen Änderung vor. Also blocksize=10MB oder 20MB oder was auch immer
Dem kommt natürlich BIP "102" am nächsten. Kann aber natürlich ernsthaft keiner mehr wollen.