32 MB könnten wir in 1-2 Jahren doch locker füllen.

Und wenn klar ist, dass man auch 128 MB Blöcke haben könnte gibt es auch sicher neue Use-Cases, dass heißt, wir würden das auch in 3-4 Jahren easy schaffen die 128 MB Blöcke zu füllen. Unternehmen wie Amazon nehmen doch derzeit überhaupt kein Bitcoin an, weil alleine sich mit dem Zweck mehrere MB pro Block füllen ließen.

Und wie schön du das beschreibst, das eins nach dem anderen kommt.
Heißt das, dass wenn wir nicht automatisch langsam in so ein abhängiges System rutschen wollen, bereits jetzt Widerstand leisten sollten?

Ich meine Roger Ver sagt ja immer, dass wir nicht das an Bitcoin zerstören sollten, bei dem wir wissen, was funktioniert, sondern das machen sollten, was wir immer schon gemacht haben, wenn das auch in der Vergangenheit funktioniert hat.

Die Blockgröße wurde  in der Vergangenheit von Bitcoin ohne Hard Fork mehrmals angehoben. Wenn es Hard Forks gab waren diese nicht umstritten. Also sollten wir doch bei dieser Vorgehensweise bleiben.

Es war immer einfach genug einen eigenen Full Node auf dem eigenen Computer laufen zu lassen, so dass es viele gab und man als SPV Client sich keine Sorgen um die Sicherheit machen musste.

Bitcoin hatte immer den größten Netzwerkeffekt von allen Kryptowährungen.

Warum wollen wir diese Eigenschaften zerstören indem wir die Blockgröße mit einem umstrittenen Hard Fork anheben, der zu einem Chain Split führt und damit aktiv den Netzwerkeffekt untergräbt?

Warum bleiben wir nicht bei den Methoden, bei denen wir wissen, dass diese auch in der Vergangenheit funktioniert haben?
-Ein Netzwerk
-Ein Bitcoin
-Keine umstrittenen Forks, die zu Chain Splits führen können
-Erhöhung der Transaktions Kapazität

P.S.
Ich persönlich finde nicht, dass ein Full Node unbedingt noch auf einem Raspi laufen können muss


Warum sollten Shops nicht einfach Bitpay nehmen?
Die Maschine kostet ja nicht nur 20.000$ in der Anschaffung, sondern auch einen hohen, laufenden Unterhalt, z.B. Strom, Versicherung, Gebäude, Personal (Ingenieure) etc.