Bigblocker, Smallblocker, hauptsache man bleibt locker

FK , Ruhrgebiet, Mittwoch, 11.10.2017, 16:28 (vor 3014 Tagen) @ Zarathustra
bearbeitet von unbekannt, Mittwoch, 11.10.2017, 16:33

Saluti FK!

Gott zum Gruße :)

Zufällig gab es auf der Bitcoin-segwit2x Mailingliste gestern eine Antwort von Hubert Maslin, die mich zum Nachdenken gebracht hat. Ich weiss noch nicht wohin dieser Post führt, aber schaun mer mal.

Er spricht nämlich etwas an, was für mich und viele andere Leute mit Informatikbackground selbstverständlich, aber für Leute aus Marktwirtschaft vielleicht totales Neuland ist. Es geht dabei um die Funktionsweise freier Softwareprojekte.

Hier ein Zitat:

I get your frustration that the ecosystem resists a lot to something that's
a no-brainer upgrade for you, but this resistance is a feature, not a bug

Hier der ganze Post: klick

Ich denke genau das ist der Knackpunkt. Bitcoin ansich mag ja eine Revolution der Finanzwelt sein, der Entwicklungsmodus als Open Source Projekt ist es ganz und gar nicht. Linux z.B. ist ein weiteres Projekt, welches genau so funktioniert.
Wer dessen Geschichte seit dem Ende der neunziger Jahre verfolgt hat, sieht genau die gleichen Muster. Immer wieder kollidiert das Business der Firmen, die mit Linux gutes Geld verdienen mit der Projektleitung. Scheinbar simple Änderungen werden gar nicht oder erst nach endlosen Diskussionen adaptiert, alles folgt vorbestimmten Prozeduren und man kann es nicht abkürzen, das Steuer übernehmen und das ganze Projekt in eine bestimmte Richtung lenken, egal wieviel Geld man drauf wirft.
Und exakt deswegen ist das ganze so erfolgreich.

Für mich sind solche Prozesse privat und beruflich völlig normal. Wenn irgendwelche Aspekte unklar sind und Entscheidungen nicht nachvollziehbar erscheinen, schaut man in den Code, Github, die Mailingliste und die IRC Archive und kann dort bis ins letzte Detail nachlesen, wie es dazu kam dass alles so ist, wie es ist. Und in 99% der Fälle wird man feststellen, dass die Entwickler in Anbetracht der Umstände die bestmögliche Lösung gefunden haben. Was nicht bedeutet, dass die Lösung aktuell immernoch optimal ist.
Jeder kann mitmachen, der Ton ist sachlich und das Klima konstruktiv. Wer also etwas Einfluss nehmen möchte muss gute Argumente haben, den Code dazu liefern und mit allen Stakeholdern kollaborieren um den Change in den Hauptentwicklungszweig aufnehmen zu lassen - oder halt das Projekt forken, wenn es unüberwindliche Differenzen gibt. Auch das ist völlig normal und passiert ständig in der Open Source Welt.

Genauso wie bei Linux gibt es auch um Bitcoin herum ein paar Echokammern, namentlich die bitcointalk Foren, Twitter, /r/bitcoin, /r/btc und ein paar andere Seiten in denen sich Massen von Leuten tummeln von denen jeder eine Meinung, aber die wenigsten eine Ahnung haben. Und natürlich gibts da dem menschlichen Naturell entsprechend Personenkult, Klatsch und Tratsch, epische Kommentarschlachten, Rufmord, Rädelsführer und Cliquenbildung.
Das ignoriert der Entwickler gefliessentlich oder mischt in seiner Freizeit munter mit weils ihm Laune macht. Ändert alles nichts daran, dass man sich am morgen nach einem Twitterwar wieder gegenseitig den Code reviewed oder Aspekte eines Pull Requests diskutiert. Genau das war z.B. neulich im BTC1 Repo des aus Sicht der BitcoinCore-Echokammer Oberbösewichtes Jeff Garzik passiert. Er fügte eine Opt-In Replay Protection ein und lud zum Review. Ein paar Bitcoin Core Entwickler haben sich das angeschaut und auf potentielle Probleme hingewiesen, woraufhin die Änderung zurückgezogen wurde und nun überarbeitet wird. Alles Business as usual bei freien Softwareprojekten. Dass in den Echokammern aus dem simplen Vorgang wieder ein erfolgreich zurückgeschlagener Angriff des Schurken Garzik auf das wohlgehütete Gold von Burgfräulein BitcoinCore wurde ist halt genauso unterhaltsam wie Bild der Frau lesen: Der eine mags, der andere nicht, aber in einem sind sich alle einig: Es ist nicht von belang.

Aber zurück zum eigentlichen Thema:
Die Skalierungsdebatte wurde in den Echokammern sachlich falsch zur Bigblocker vs Smallblocker debatte verkürzt. Dabei sind sich alle einig, dass die Blöcke größer werden sollen. Das Projekt hat eine Roadmap nach der erst die Transaktionsgrößen selbst optimiert werden. Segwit ist dabei der erste Schritt und ein paar weitere werden folgen. Wenn das ausgeschöpft ist, werden die Blöcke größer gemacht und gleichzeitig bastelt man am Layer 2 für exponentielles scaling.
Ein paar Leuten schmeckt die Roadmap überhaupt nicht, also haben sie geforkt. Es ist nicht der erste und wird auch nicht der letzte Fork bleiben, so what. Was der Markt dazu sagt ist ersteinmal nebensächlich.
Genauso wie sich Multimilliardenunternehmen mittlerweile an Linuxforks, inkompatible Patchsets und eiskalte Stinkefinger seitens Projektleitung gewöhnt haben, werden sich eben auch die Nutzer von Cryptowährungen an Forks der Blockchain gewöhnen. Das gehört einfach mit zur Cryptogeld-Revolution und ist ums mit Huberts Worten zu sagen noch ein weiteres Feature und kein Bug.

--
Regeln sind dazu da, damit man nachdenkt bevor man sie bricht.
Terry Pratchett