TLDR:
Peter R. ignoriert in seinem Vortrag, dass es neben dem P2P Layer einen Consensus-Layer gibt, bzw. unterstellt der absoluten Mehrheit, dass diese vorab einen Hard-Fork durchführt und Segwit auf dem Consensus-Layer deaktiviert.
Dann ist der Angriff allerdings kein Angriff mehr, weil es überhaupt keine gültigen Witnessdaten mehr auf dem P2P Layer gibt, die man vorenthalten könnte, und der Sinn des Vortrages ist ebenso ad absurdum geführt.
Zudem gibt es keinen standardisierten P2P Layer bei Segwit Knoten um Segwit-Blöcke ohne Witnessdaten zu übertragen.



Also das mit dem Signature Pruning geht theoretisch bereits jetzt.
Unter bestimmten Bedingungen wäre das sogar sinnvoll, weil Bitcoin Unlimited beim IBD die Signaturen zwar runterlädt, aber nicht überprüft, also Bandbreite verschwendet.
Bitcoin Core unterstützt eine ähnliche Funktion mit Assumevalid(), verschwendet also praktisch auch Bandbreite, wenn man sich nicht für die Signaturen in ganz alten Blöcken interessiert und diese nicht anderen zur Verfügung stellen möchte.

Das wirklich neue an Segwit ist in diesem Fall nur, dass man jetzt dafür theoretisch einen standardisierten Weg hat, welcher rückwärtskompatibel mit bestehenden Nodes ist und zwar auf dem P2P-Layer, als auch auf dem Consensus-Layer.
Man könnte das auch für die alten Transaktionen standardisieren - und zwar für den P2P Layer unabhängig vom Consensus Layer.

Das Problem ist dann die Datenintegrität... Bei Segwit ist das über den 2. Merkle-Tree abgesichert.
Aber bei den alten Transaktionen?
Woher weiß man, ob der Merkle-Tree bzw. die TXIDs zu den Transaktionen ohne Signaturen passen?
Aber auch das lässt sich lösen, zum Beispiel mit UTXO-Commitments, oder "known-good-UTXO" bei bestimmten Blöcken.
Oder eben auch mit einem 2. Merkle Tree auf dem P2P Layer mit normalized TXIDs, bzw. einem kombinierten aus legacy und normalized TXIDs.
Somit wäre auch die Historie erhalten. Man ist ja nicht gezwungen nur auf die bisherige Art und Weise die Historie aufzubauen.

Wie man das eine Node in seiner lokalen Datenbank speichert ist dann noch mal komplett unabhängig davon, da kann man noch viel leichter die Signaturdaten prunen.

Auch noch wichtig zu wissen - Miner haben einen eigenen P2P-Layer (z.B. FIBRE / Xthin-Xpedited).
Und wenn Miner den Consensus Layer ignorieren, dann sorgen die ökonomischen Nodes dafür, dass die Miner bestraft werden und sich dann doch wieder an die Consensus Regeln halten.

Das heißt der Angriff mit Segwit ist nur bei Nodes möglich, welche auf dem Consensus-Layer kein Segwit überprüfen und auch auf dem P2P-Layer keine Witnessdaten erfordern (zum Beispiel Bitcoin Unlimited).
Es gibt nämlich keine Segwit-Kompatiblen Knoten, die bei einem Segwit-Block auf dem P2P-Layer diesen ohne Witnessdaten akzeptieren.
Das heißt man müsste erstmal so einen Client implementieren, damit der Angriff überhaupt bei Segwit-Knoten funktioniert - haha sehr lustig.



Was jetzt wirklich wie wann gepruned wird bleibt abzuwarten - meines wissens gibt es noch keine Software die
A(S) - B(S) - C(S) - D(S)
zu
A - B - C - D(S)
prunen kann, auch wenn das theoretisch sehr einfach möglich sein sollte.

Weiß noch nicht genau, wie das auf dem P2P Layer mit der Standardisierung ist. Ich denke dann müsste man NODE_WITNESS nicht nach außen als Service anbieten, was also bedeutet, dass der eigene Knoten nach außen zunächst mal überhaupt keine Segwit Signaturen liefern kann.
Von anderen Knoten würden die Blöcke aber trotzdem nur akzeptiert werden, wenn diese auch die Witnessdaten(Signaturen) beinhalten, der Signaturdaten prunende Knoten würde also alles weiterhin validieren. Aktuell geht das aber noch nicht.

Ohne die Signaturdaten (egal, ob Segwitdaten oder nicht) akzeptiert jedenfalls ein Segwit bewusster Knoten den Block nicht.
Der Angriff funktioniert nur, wenn man ökonomische Knoten davon überzeugen kann mit einem Hard-Fork Segwit zu deaktivieren.

Die Miner im Beispiel von Peter R. können also die Bitcoins garnicht klauen, weil Sie ein Bitcoin (Altcoin) mit neuen Regeln erschaffen haben.
Das es keinen Beweis dafür gibt, dass die Bitcoins geklaut wurden ist irrelevant - bzw. sie wurden nicht geklaut, weil die Miner in Ihrem Hard-Fork die Segwit Outputs zu Anyone-Can-Spend outputs umgewandelt haben und sich also an alle Regeln gehalten haben.

Wenn man die Witness Daten vom Block zurückhält, hält man praktisch den ganzen Block zurück.
Dazu müsste man eine neue P2P Standardisierung einführen, weil Segwit-Knoten nur beides gleichzeitig übertragen.

Das Miner über ihre eigenen P2P Layer kurzfristig per Spy-Mining etc. schon einen neuen Block bauen, damit die Mining-Hardware nicht sinnlos Däumchen dreht, bis der Block durch den Consensus-Layer durch ist ändert nichts daran, dass der Block durch den Consensus-Layer durch muss um gültig zu sein - und ohne Witness-Daten kommt er da nicht durch, verteilt sich also auch nicht über den P2P Layer von normalen Nodes.
Unter den dann alten Regeln (also mit Segwit), die von allen wichtigen ökonomischen Knoten angewandt werden haben sich die Bitcoins also niemals bewegt.

Ich möchte mal sehen, wie die Miner es schaffen Bitcoins mit einem Hard-Fork zu klauen, wenn diese es nicht mal schaffen einen Hard-Fork mit 2 MB Blocksize durchzudrücken - das ist einfach lächerlich.


Edit:
Weil von den Hardforkern gerne mal letzter Zeit wieder BIP140 mit normalized TXID ins spiel gebracht wurde -> Erlaubt auch Signature pruning, ähnlich Segwit, führt also zu den ähnlichen Problemen und jede Transaktion muss 2 mal gehashed werden -> UTXO-Size verdoppelt sich
Malleability ist ein Arschloch  
BIP140 ist ganz schön kompliziert - finde es ungefähr so kompliziert wie segwit - gibt wohl auch deswegen keine Implementierung die ich finden konnte

Edit2:
https://www.reddit.com/r/btc/comments/6jsu46/the_risks_of_segregated_witness_possible_problems/
Gmax beschreibt da ganz gut, warum das nur FUD ist für normale Knoten

Edit3:
Technische Details zum P2P Layer für Segwit: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
Da kann man auch gut sehen, dass es keine standardisierte Möglichkeit gibt nur die Signaturdaten zu übertragen

Um das ganze nochmal etwas zu vertiefen.
Man kann bereits jetzt sein eigenes P2P Serialisierungs-Format festlegen.
Das ist ohne Soft-Fork etc. möglich, weil es nicht den Consensus-Layer direkt betrifft.

Miner könnten also bei einer alten TX die Signaturdaten komplett wegsparen und stattdessen untereinander die TX-ID übertragen.
Für das Mining würde das komplett ausreichen.
Die Incentives bestehen in ähnlicher Form bereits jetzt unabhängig von Segwit.

Das ist alles eher theoretisch.
Die Signaturen sind ja trotzdem mit dem Block verknüpft, das heißt es verhält sich auch weiterhin so, wenn man seine Software updated.

Die Annahmen sind einfach sehr weit hergeholt. Aus Sicht eines Segwit Clients sind das auch kein normaler Block und ein Segwit-Extension Block, sondern ein einziger Block.

Du kannst nicht einfach Signaturen rausnehmen
Die Kette A(S) --> B(S) --> C --> D --> E(S) würde aus Sicht eines Segwit Nodes ungültig sein, sondern die Kette würde nur A(S) --> B(S) sein.

Dann kommt es eben zu einem Chain Split, weil das technisch gesehen ein Hard-Fork von einem Miner ist.
Gibt es irgendeine Exchange, die angekündigt hat, dass Sie Segwit kategorisch ablehnt?
Wo soll man dann solche Bitcoins verkaufen?

Und die alten Nodes leiten die Transaktionen ja nicht weiter, weil das Non-Standard-Tx sind.

Miner sind auch jetzt nicht gezwungen Signaturen zu überprüfen, sondern können auch auf ungültige Blöcke problemlos neue Blöcke auf ungültige Blöcke minen - nimmt eben keiner an, deswegen machen die das nicht.
Das ändert sich ja nicht.

Wen interessiert es, wenn die Miner temporär ein eigenes Netzwerk mit ungültigen Blöcken aufmachen?

Edit:
Hab mir den Artikel jetzt noch mal in Ruhe durchgelesen und kann mich nur wiederholen:
Wen interessiert es, wenn die Miner temporär ein eigenes Netzwerk mit ungültigen Blöcken aufmachen?
Wo soll man dann solche Bitcoins verkaufen?

Exchanges werden immer Full Nodes laufen lassen und niemals ungültige Blöcke annehmen, also können Miner auch keine Segwit Transaktionen stehlen
Der Autor verschweigt, dass er Annahmen gemacht hat unter welchen Bedingungen seine Beobachtung gelten, nämlich, dass Exchanges die Blöcke nicht vollständig überprüfen, bzw. Miner alleine die Regeln festlegen, also meiste Hashpower = Regeln, was nun einfach mal so nicht der Wahrheit entspricht.

Hallo, melde mich mal wieder zurück - hatte letzter Zeit viel zu tun.
Falls mal irgendwo Interesse besteht (v. a. zu technischen Fragen) könnt ihr mich aber immer per PM anschreiben und ich schaue, was ich tun kann.

Habe mir das auch mal angeschaut.
Fand ich schon extrem unseriös, weil er so viele Annahmen gemacht hat und die nicht erläutert hat, unter anderem:
Miner legen die Regeln fest und die anderen müssen folgen - Implizit ist das nämlich ein Hard Fork
Andere benutzen keine Segwit kompatible Software, weil sonst würden diese die Blöcke überhaupt nicht annehmen ohne Witness Daten

Das Problem besteht grundsätzlich schon (siehe Peter Todd aus 2015 https://twitter.com/petertoddbtc/status/881202125312847874), aber die Blöcke würden ja niemals bei einem Teilnehmer ankommen der Segwit Regeln überprüft, also könnten die Miner ihre Fake-Bitcoins wohl auch nicht verkaufen. Ich könnte mir vorstellen, dass man auf die Lösung von Peter Todd verzichtet hat, weil dann Segwit nicht mehr Opt-In für Miner wäre.

Edit:
Siehe auch Vitaliks Kommentar im Twitter dazu.
Sehe das genauso - die Miner könnten genauso gut einen Hard Fork machen um auch die normalen Signaturen (nicht Segwit) zu ignorieren.

So viel zum Schreiben
Ich lass mir mal Zeit und beantworte das Stück für Stück.

@Christoph
Jetzt sehe ich erst, dass du Segwit berechnest, indem du 10% addierst, was für native Segwit Transaktionen nicht notwendig ist, das erklärt das von dir beschriebene Verhalten.
Fairerweise müsstest du dann noch einen Faktor einbauen - Anteil Native Segwit zu Nested P2SH Segwit.

Ich war mal so frei und hab das angepasst und für den Start 50% angenommen - aber jeder ist ja frei das anzupassen. Bis Segwit aktiviert wird, vergehen ja sowieso noch einige Wochen.
http://js.do/code/156939

Die sim sollte so passen - wenn man es auf 0 stellt kommen meine alten zahlen raus, wenn man es auf 1 stellt kommen deine alten Zahlen raus.

Warum findest du Native Segwit Adressen eigentlich so kompliziert? Ich persönlich finde die sogar einfacher als die alten Adressen.
Die sind zumindest wesentlich einfacher zu implementieren als die Nested P2SH Adressen.

Ich halte eine rasche Nutzung von Segwit überhaupt nicht für unrealistisch. Wir sehen, dass viele Leute im Augenblick sogar willens sind Bitcoin komplett zu verlassen und Altcoins zu nutzen - im Vergleich dazu ist ein Umstieg auf Segwit doch trivial. Über 80% zu kommen wird aber sicher schwerer.

@Christoph
Meine Zahlen zu Schnorr waren komplett aus der Luft gegriffen, da es mir ausschließlich um den Mathematischen Zusammenhang ging. Falls ich mal was sehe, oder extrem viel Zeit habe werde ich das hier posten.

Also ich hab mir dein Simulator angeguckt - irgendwas stimmt da nicht - kleine Prüfung zeigt, dass die Kapazität unter 1 MB sinkt bei deiner Simulation, wenn Segwit mehr als 0 Prozent hat.

Ich hab mal meine Simulation hinzugefügt:
http://js.do/code/156862

Noch mal kurz vorab - Ich finde Core ganz und gar nicht perfekt, aber ich sehe Core immer noch als das Beste, was wir momentan zur Verfügung haben.
Meine Einschätzung ist, dass Segwit kurzfristig reicht, Schnorr eine kleine Hilfe sein kann, aber das reicht natürlich noch alles nicht. Ich halte einfach Chain Splits für kontraproduktiv, weswegen ich wenig von BIP148 halte, sowieo noch weniger von BU, was aber auch mit dem schlechten Track Record zu tun hat. Viel wichtiger als meine Einschätzung ist für mich selbst aber auch, was ich glaube, dass andere denken. Und da sehe ich einfach sehr viel Vertrauen in Core, ob das nun berechtigt ist oder nicht.

Ich freue mich übrigens, dass Parity und Bcoin auch fleißig am entwickeln sind und könnte mir durchaus vorstellen Bcoin mit Extension-Blocks zu nutzen.

Ich bin tatsächlich der Meinung, das wir auf absehbare Zeit keinen Hard Fork brauchen, denn es gibt genügend alternative Möglichkeiten die Transaktionskapazität zu erhöhen: z.B. Sidechains (RSK Rootstock), Segwit, Extension Blocks, Schnorr, MAST und Lightning-Network, die alle keine Chain Splits hervorrufen.

Wie bereits gesagt - noch vor 1-2 Jahren sah die Situation anders aus - ein 2 MB Hard Fork war da eine gute Option zum Status quo, mittlerweile haben wir aber viele neue Technologien, die nicht alle von Core kommen.

Der Witz ist, dadurch das Segwit nicht aktiviert wird kann man auch nicht beweisen, das Segwit nicht reicht.
Genauso ist es mit BU - man kann schwer beweisen, dass es funktioniert, aber man kann auch nicht beweisen, dass es EC langfristig funktioniert, weil es das bisschen gebliebene Dezentralisierung stark aushebelt - Willkommen Paypal 2.0.
Wir drehen uns im Kreis mit sich widersprechenden Behauptungen.
Ich finde es schade, dass du das als Verleumdung siehst, aber jedem steht seine Meinung zu.

Ich versuche es nochmal:
Als normaler Nutzer bringt es überhaupt nichts, wenn ich EB/AD setze, da werde ich höchstens irgendwo als Sybill Angreifer abgetan, weil Signaling von Nodes wertlos ist, sondern nur die ökonomische Power die hinter den Nodes steht. Es fällt aber kaum auf, wenn jeweils nur einige wenige Nodes bei einer erneuten Erhöhung der Blocksize verschwinden. Und man weiß ja auch nicht, was das EB/AD bedeutet, das die Nodes signalisieren. Könnte auch heißen, bei Überschreitung will ich keinen eigenen Node mehr betreiben, sondern werde einen SPV-Node nutzen. EB/AD können höchstens Exchanges durchsetzen, aber Exchanges bleiben lieber neutral, wie wir aktuell sehen, also ist auch da nichts zu erwarten. Und als SPV-Node kann ich sowieso nichts machen. Also wird EB/AD zu 99% von den Minern festgelegt. Miner haben aber ihre ganz eigenen Interessen, sonst wäre Segwit meiner Meinung nach schon aktiv, denn wir brauchen das unabhängig von der Blockgröße um technologisch mit Altcoins  mitzuhalten.

Segwit mag vielleicht eine größere technische Änderung sein als ein Block Size Hard Fork, aber der Hard Fork ist sicherlich eine wesentlich größere Ökonomische und Politische Änderung. Und Segwit ist als MASF zumindest ohne großes Risiko zu aktivieren, sonst hätten wir schon Auswirkungen bei Litecoin gesehen. Mit reichlich Kapital ausgestattete Gegner von Segwit gibt es zumindest, die sicherlich erfolglos versuchen zu zeigen wie gefährlich Segwit ist, komischer Weise hört man aber nichts.

Für mich ist das alles ein reines Machtspiel mit den Hard Forks. Ggf. geht es auch um verletzte Egos - jedenfalls gibt es keine technischen Gründe.

Die Blockweight Formel ist übrigens überhaupt nicht seltsam, sondern sorgt endlich dafür, dass es ungefähr genauso viel kostet ein UTXO-Eintrag zu konsumieren, wie diesen zu erstellen und hilft somit gegen UTXO-Bloat und das Gebühren zu hoch sind um UTXOs mit geringem Betrag noch auszugeben. In einem Hard Fork sollte man das sinnvoller Weise auch für alte Transaktionen einführen - schlägt Luke-Jr übrigens immer wieder vor.

Du meinst die Vereinbarung, wo sich nur ein paar Devs von Core mit denen getroffen haben, die weder für alle Nutzer, noch für Core sprechen können und die Vereinbarung, die die Miner direkt gebrochen haben, indem ein Miner Bitcoin Classic genutzt hat?


Ich meinte, wenn BU sich mit 100% durchgesetzt hätte, weil die Mehrheit nicht an der Technik interessiert ist, was aber so wie es aussieht nie passieren wird. Dazu ist es aber schon zu spät - ich gehe auch davon aus, das ETH zunächst mal Bitcoin in der Marktkapitalisierung überholen wird. Und BU könnte das höchstens zementieren, denn aktuell würde das mit Sicherheit auf Chainsplits rauslaufen und nur die Position von ETH als klare Nummer 1 festigen. Nur weil auf einmal BU sich durchgesetzt hätte wäre ja nicht alles sofort super einfach. Die Probleme würden höchstens versteckt und verschoben.

So war das nicht gemeint. Core zu kritisieren ist legitim und es ist auch nicht alles ganz in Ordnung, was von Core kommt.
Ich meinte nur damit, das man es einfach besser machen soll - dann wird das auch seine Anhänger und langfristig die Mehrheit an sich binden können. Die bisherigen Versuche haben es aber offensichtlich nicht geschafft und kläglich versagt.

Stimme dem mal teilweise zu - man kann so mehr Miner nutzen. Also ich kann mich zumindest daran erinnern gelesen zu haben, dass einige Miner ihre Hashrate drosseln mussten, weil es nicht genügend Strom aus Wasserkraft gab, wegen niedriger Pegelstände. Außerdem ist die Kühlung so einfacher und man kann mehr Miner in einem Gebäude unterbringen.
Die kosten pro Hash/s sinken in jedem Fall, was man damit macht ist dem Miner überlassen.

Natürlich kann man die zentralisieren und kontrollieren, jedoch viel schwerer als die Miner, da man keine neue Hardware braucht um einen neuen Kanal/Hub/Netzwerk aufzusetzen, sondern nur Software, die für jeden verfügbar ist. Während Miner zudem auf günstige Energie angewiesen sind und sich deswegen nicht aussuchen können wo sie minen ist man mit 2nd Layer Lösungen flexibler und kann auf andere Länder ausweichen. Zudem bleibt die Wahlfreiheit immer noch beim Nutzer, welchen Service er nutzen will.

Naja...
Segwit ist in fast allen Punkten eine Verbesserung, gegenüber dem, was wir jetzt haben.
Native Segwit Transaktionen (P2WPKH) sind kleiner als normale Transaktionen (P2PKH), das sollte man auch erwähnen. Große Anbieter können direkt Native Segwit Transaktionen nutzen - für normale Nutzer müssen wir warten bis das Bech32 / BIP173 Adressformat in die Clients eingebaut wird - aber dazu brauchen wir weder einen Soft Fork, noch einen Hard Fork.
Die für den Übergang Netsted-P2SH Transaktionen sind auch nicht grundlos größer.
Man sollte dann auch erwähnen, dass die 20% nicht durch reine Ineffizienz kommen, sondern durch eine Erhöhung der Sicherheit von 80 bit auf 128 bit, da 80 bit mittelfristig nicht mehr als sicher zu betrachten sind.
https://bitcoincore.org/en/2016/01/26/segwit-benefits/#increased-security-for-multisig-via-pay-to-script-hash-p2sh

Hallo habe gerade keine ausreichende Zeit - schreibe später noch mal zu den anderen Punkten.

Das Rechenbeispiel habe ich so gewählt, wie ich es kurzfristig nach einer Aktivierung von Segwit und Schnorr als realistisch ansehe - die tatsächlichen Einsparungen sind noch viel größer - ich habe da praktisch mal den Worst Case ausgerechnet, die Zahlen haben aber keine besondere Bedeutung, sondern sind eher zufällig gewählt. Bei 100% Segwit sollten wir ungefähr ein Verhältnis von 25:75 und nicht 40:60 haben.

Das heißt in meinem Beispiel ist höchstens die Hälfte der Transaktion Segwit und nur ein kleiner Teil der Segwit Transaktionen Schnorr - sind einfach beliebige Zahlen, mit denen ich nur zeigen wollte, dass das Prinzip grundsätzlich funktioniert. Ob das ausreichend ist, ist ein ganz anderes Thema - werde mir dein Modell später in Ruhe angucken.
Aber nur mal so am Rande - bei Multisig spart Schnorr ganz leicht 50%.

Bei den aktuell hohen Gebühren gibt es zumindest zumindest Anreize, dass die Verbreitung schnell steigt und somit auch die Blockgröße.

Ich würde mich freuen, wenn du deine Beurteilungen über mich nicht so persönlich schreiben würdest (du bist kein Manager z.B. ist doch unnötig), gebe mir auch Mühe das nicht bei dir zu tun, hoffe das gelingt mir soweit.

Tatsächlich habe ich ursprünglich einen betriebswirtschaftlichen Hintergrund und bin erst später auf Informatik umgestiegen. Ich halte das auch für keine besonders gute Kapazitätsplanung, aber eben für leicht erreichbar. Wenn Hard Forks nicht so problematisch wären, dann hätte ich persönlich ein kleineres Problem mit der Blockgröße.

Ein Vergleich - unsere Demokratie ist herrlich ineffizient. Ständig gibt es irgendwelche Richtungswechsel. Warum akzeptieren wir das? In China ist doch alles so viel effizienter, wenn die zum Beispiel ein großes Infrastrukturprojekt anpacken. Aber da gibt es eben andere Nachteile - Menschenrechte etc.. Ich sehe das bei Bitcoin ähnlich. Die Organisationsstruktur ist ziemlich ineffizient, aber ich und andere akzeptieren das, weil wir die Nachteile von den zentralen Systemen kennen (z.B. € und EZB), bei denen wir uns äußeren Interessen beugen müssen - und ich befürchte, dass wenn man die vermeintlich einfache Lösung Blocksize Hard Fork so in den Fokus rückt und andere Verbesserungen wie Segwit bekämpft, ganz schnell bei einem System landen, bei dem wir die Eigenschaften verlieren, die Bitcoin gegenüber bisherigen System einzigartig machen und somit auch der Wert noch stärker als durch die aktuellen Probleme unterhöhlt wird.

Ja es ist manchmal einfach alles zum kotzen, aber ich sehe den Status quo und Segwit, etc. als das geringere Übel an.
Ich denke, wenn BU sich durchgesetzt hätte, würden wir auf mittlere Sicht sicherlich wesentlich höhere Preise haben als jetzt, langfristig (5+ Jahre) würde Bitcoin aber extreme Probleme (eher politisch als technisch) bekommen und unter den aktuellen Wert fallen.

Was mir gerade noch einfällt - auf der Mailingliste hatte Sergio Demian Lerner mal ein paar Simulationen mit Segwit durchgeführt - muss letzten Monat gewesen sein.

Bitte nicht persönlich nehmen, aber da ist dein Wissen über Segwit einfach fehlerhaft.
Es gibt keine 1+3 Logik bei Segwit - wo hast du das her?

Blockweight <= 4.000.000 = Non-Segwit-Data * 4 + Segwit-Data

Das ist ein kleiner, aber feiner Unterschied, der dazu führt, dass Schnorr eben doch die Transaktionskapazität erhöht.
Das wurde ja extra so gewählt, damit es nur ein 1D-Problem bleibt und nicht ein 2D-Problem wird, was zu allerhand von Schwierigkeiten, wie zum Beispiel genau dem, was du beschrieben hast führen würde.

Edit:
Rechenbeispiel:
Non-Segwit-Data = 700 kB -> 2.8 MB Weight
Segwit-Data = 1.2 MB

Ein legacy Node sieht 700 kB, der Block ist aber maximal voll nach Segwit Regeln, da Block Weight 4 MB ist.

Wenn wir jetzt 200 kb Segwit-Daten durch Schnorr sparen können:

Non-Segwit-Data = 700 kb
Segwit-Data = 1 MB

Block Weight = 3.8 MB -> Wir haben also 0.2 MB noch frei, also entweder 50 kb non-segwit data oder 200 kb segwit data bzw. eine Mischung daraus - Schnorr schafft also auch direkt Platz, gleiches gilt auch für MAST.

Das Problem besteht ja nur so lange, wie die Nodes nicht upgedated worden sind, also nur temporär.
Bitcoin Core warnt einen ja ausdrücklich, wenn ein unbekannter Softfork aktiv ist.

Es gibt aber Libraries und andere Projekte, die nicht mit dem aktuellen Client kompatibel sind, also kann man nicht mal eben einfach alles umstellen. Siehe Debian, die einige Zeit gebraucht haben um überhaupt den zugehörigen Compiler zur Verfügung zu stellen.

Als SPV-Node oder Thin-Client hat man ja sowieso ein anderes Trust-Modell, als bei einem Full-Node, was für die Mehrheit absolut ausreichend ist. Die Signaturen auf einem Thin-Client zu prüfen bringt natürlich nur ein wenig. Ist so, wenn man die Signaturen überprüft, als ob man ein Haus hätte mit zwei Türen. Die eine Tür sicher abgeschlossen und die andere direkt daneben sperrangelweit offen. Das hat sicher auch was mit Psychologie zu tun, das es für unwissende eben ein besseres Gefühl ist, wenn man die Signaturen überprüft, denn eigentlich könnte man eine Transaktion mit falscher Signatur ja gar nicht empfangen, weil diese nicht weitergeleitet wird - wenn man also eine falsche Signatur empfängt, findet gerade ein MITM Angriff statt - die Person könnte einem jedoch auch einfach gefälschte 0-conf Bitcoins schicken.

Bei bestätigten Transaktionen sorgt das allerdings auch mit einem SPV-Node dafür, dass man nur einer gültigen Blockchain folgt, auch wenn diese weniger kummulierten PoW als eine andere Blockchain hat, so lässt sich etwas ökonomischer Druck aufbauen.
Deswegen ist die Aktivierungshürde bei Soft Forks historisch auch immer so hoch gewesen, damit immer sicher gestellt war, dass so eine Situation von vornherein praktisch ausgeschlossen ist und nur Leute die zu faul sind zum updaten oder nicht updaten können dies nicht machen müssen, sondern andere Nodes und Miner die Aufgabe übernehmen.

Achja - wie kann ich in einem BU-Szenario eigentlich Einfluss auf die Blockgröße nehmen, wenn ich ein SPV-Node habe? Und wie wirkt sich der Umstand darauf aus, dass prozentual immer mehr Leute in einem BU-Szenario nur ein SPV-Node nutzen würden?

Ich versteh, was du sagen willst, sehe das aber einfach anders.

Ehrlich gesagt sehe ich nicht, dass BU dem User wirklich Entscheidung gibt - Segwit, Extension Blocks, etc. kann man überhaupt nicht wählen - und die Einstellung mit EB/AD finde ich so herrlich wirkungslos, dass diese nur eine Entscheidung ermöglicht, ob man überhaupt noch Bitcoin nutzen will oder nicht. Außerdem brauchen die noch lange um ihr von den Hacks beschädigtes Ansehen zu reparieren.

Core muss nicht führen, weil Bitcoin nicht Bitcoin Core ist - Bitcoin ist so viel mehr als Core.
Da ist ziemlich viel Scheiße in der Vergangenheit passiert - von allen Seiten, aber meines Wissens hat Core niemals als Organisationseinheit etwas zugesagt und sich nicht daran gehalten.
Meiner Meinung nach wäre 2014-2015 das beste ein 2 MB HF gewesen, dann hätte man sich genug Zeit verschaffen können.
Jetzt ist eben Segwit die wesentlich sichere Variante um mehr Tx/s Onchain zu ermöglichen.

Und klar - für Hard Forks braucht man natürlich entweder eine zentrale Stelle die führt oder ein starken Konsens, damit das nicht im Chaos endet.

Wow Christoph.
Ich würde es schön finden, wenn wir uns alle mal wieder ein bisschen beruhigen.
Segwit ist vor allem eine ordentliche technische Verbesserung des Transaktionsformats, die viele technische Schwachstellen (Fehler) des ursprünglichen Bitcoin Transaktionsformats behebt. Vieles, was mit anderen Kryptowährungen möglich oder viel einfacher ist, wird dadurch endlich auch mit Bitcoin möglich. Um konkurrenzfähig in der technischen Entwicklung zu bleiben gegenüber anderen Kryptowährungen also je nach Ansicht sogar ein notwendiges Update.
Ein 2MB Hardfork und Segwit sind technisch voneinander vollkommen unabhängig.
Nur wenn Segwit wirklich reichen würde, würde dies einen 2MB Hardfork definitv ausschließen.

Hey Christoph, gibt noch einiges anderes, wozu ich schreiben will. Aber aufgrund der kürze der mir zur Verfügung stehenden Zeit beschränke ich mich mal darauf:

Core führt nicht, Core hat auch überhaupt kein Mandat um zu führen. Das hat niemand alleine bei Bitcoin.

Core als Organisation hat natürlich Einfluss - aber wie man an den unterschiedlichen Meinungen z.B. zu BIP148 sieht (Luke vs. Gmax), tritt Core kaum als Organisation auf, sondern Personen die an Core mitwirken treten als Individuen nach außen auf.

Ich kann verstehen, dass viele sich nach jemandem sehnen, der Bitcoin leitet, denn das ist einfacher zu verstehen, so hat sich Bitcoin aber nicht entwickelt.

Es ist sinnlos Core für irgendwas zu beschuldigen. Wenn man etwas ändern will, dann muss man eben eine Alternative bieten, die die Mehrheit bevorzugt, weil sie eindeutige Vorteile sehen.

Und wenn ich Leute sehe, die sich darüber ärgern, wenn andere einfach stur Core folgen, obwohl aktuell die Gebühren so extrem hoch sind, zeigt das nur, wie kläglich alle Alternativen bisher versagt haben.

Für mich ist zumindest klar, dass Bitcoin auch weiterhin als Zahlungsmittel nutzbar bleiben muss, sonst wird es langfristig durch eine andere Alternative ersetzt. Und Bitcoin als Zahlungsmittel muss nicht Bitcoin als Wertaufbewahrungsmittel (digitales Gold) ausschließen, wenn die Prinzipien von Bitcoin (v.a. Dezentralisierung) nicht verraten werden.

Ich denke das geht mindestens um den Faktor 10-20 schneller, da die Fees aktuell so hoch sind.
Mal abgesehen davon - das wäre ja keine schlechte Sache gewesen, wäre der Preis für Block-Space nicht so aus dem Ruder gelaufen.
Wenn das Angebot sprunghaft erhöht wird, landen wir ja gleich bei Fee ~0

Nein!
Prinzipiell kann man sofort native Segwit Transaktionen verwenden - das wird mit BIP141 bereits komplett abgedeckt.
Allerdings muss man dann die Segwit Transaktion von Hand erstellen.

Wenn du nachlesen willst -> im BIP 141 unter Witness Program.

Der neue Vorschlag mit den BCH codierten Adressen enthält übrigens direkt den Bitcoin Script  (Witness Program) BCH codiert für Segwit
https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

Eine Adresse ist prizipiell eine Anweisung für dein Wallet, wie es den Output einer Transaktion zu erstellen hat, speziell den Bitcoin Script.
Da sich der Script für native Segwit Transaktionen vom Skript für legacy Transaktionen unterscheidet braucht man ein neues Adressformat um das benutzerfreundlich zu machen, damit ein Wallet das verstehen kann. Ohne die benutzerfreundlichkeit funktioniert es aber auch so.

Gültig sind die natürlich, sonst könnte es kein Soft-Fork sein.
Ich verstehe nicht, wie du für BU sein kannst und dann nicht den Minern vertrauen willst.
Außerdem ist es hier ja so, dass durch den Soft-Fork alle ökonomischen wichtigen Nodes dafür sorgen werden, dass die Regeln eingehalten werden. Keine Exchange wird Coins annehmen, bei der Miner einfach irgendwelche Bitcoins an sich selbst transferieren.
Und nur Nodes die Segwit unterstützen werden die TX auch weiterleiten - und zwar nur dann, wenn Sie gültig ist.
MITM Angriff für SPV Nodes bleibt genauso als Problem bestehen, unabhängig von Segwit.

Wo ändert sich da das Trustmodell jetzt genau? Und wie lange?

Das Trust Modell ändert sich doch überhaupt nicht. 0-conf war schon immer unsicher. Die hohe Anzahl an Segwit validierenden Nodes sorgt dafür, dass 0-conf aber auch nicht unsicherer wird. Und denk daran - alle Transaktionen die du bisher ausgeführt hast sind nach der Logik
auch unsicher, oder immer noch Anyone-Can-Spend, dank des OP_RETURN bugs. Irgendwann werden alle upgedatet haben - aber jeder darf eben dann updaten, wenn er es will, oder alternativ es sogar sein lassen.

Genau eben nicht - Das Guthaben bleibt in der Mainchain und wird auf einer speziellen Adresse gesammelt.
Das Guthaben was auf der Adresse ist, wird dann im Extension Block neu erschaffen.

Extension Blocks haben ein von der Mainchain unabhängiges UTXO, genauso wie Sidechains.

Innerhalb des Extension Blocks kann das dan hin und her übertragen werden, ohne dass das überhaupt Auswirkungen auf die Mainchain hat.
Erst wenn man wieder an jemand in der Mainchain senden will, verschwindet das Guthaben im Extension Block und der Empfänger in der Mainchain wird aus dem Guthaben der speziellen Adresse (praktisch gesehen ist das keine 1er oder 3er Adresse, sondern nur der script  "OP_RETURN" OP_TRUE, für den es keine äquivalente Adressdarstellung gibt - ggf. macht man das als 3er Adresse mit P2SH, ändert aber nichts am Prinzip) bezahlt.

Ohne Extension Block Unterstützung sieht man dann nur, dass man von dieser speziellen Adresse was empfangen hat.

Ja - Extension Blocks haben andere Adressen, bzw. ein anderen Bitcoin Script - Vorschlag ist hier auch das über ein Witness Program zu machen - siehe BIP141.

Wenn du mehr dazu nachlesen willst - die Spec von Bcoin ist recht gut zu lesen
https://github.com/tothemoon-org/extension-blocks/blob/master/spec.md
Ich glaube das wurde durch einen Hard-Fork gelöst oder?
Wie soll das ohne einen Vitalik bei Bitcoin klappen?

Aber warum wollen wir mit EC genau so einen Angriffsvektor überhaupt erst aufmachen um ihn dann wieder fixen zu müssen?
Wir haben auch im Augenblick keine vernünftigen pruned Nodes, weil es keine UTXO-Commitments etc. gibt.
Dann kannst irgendwann keine neuen Nodes mehr syncen -> Erzeugt alles sehr stark Zentralisierung.

Das heißt da ist einfach noch extrem viel Vorarbeit zu leisten um die Angriffsmöglichkeiten ausreichend abzuschwächen.

Ethereum hat auch seine Blockchain verändert, wegen dem DAO bug. Sowas würden wir bei Bitcoin wohl kaum machen.
Und auch deswegen ist Bitcoin zum Daten speichern aktuell konkurrenzlos.

Du kannst bei Bitcoin manche Dinge auch nicht so einfach prunen, wie bei Ethereum. Da hat einer ganz viele leere Accounts angelegt. Natürlich kann man die einfach wieder löschen - Bei Bitcoin hätte es ja nicht mal einen Eintrag im UTXO-Set dazu gegeben. Was passiert aber, wenn du in Bitcoin einfach viele dust utxos anlegst? Die kannst du nicht prunen.

Ich hab in meinem Wallet einige 1 Satoshi Dust UTXOs die irgendein spammer mal angelegt hat.

Willst du jetzt einfach alle kleinen Outputs löschen? Also die Eigentümer von Bitcoins enteignen? Das wird einen schönen Aufschrei geben.

Wir können in Bitcoin Spam nicht von normalen Transaktionen unterscheiden - außer bei den 1 Satoshi Dust Transaktionen die ich empfangen habe kann ich das für keine anderen Transaktionen sagen, ob die Spam sind oder nicht.

Bitcoin ist ja auch ein erlaubnisfreies System.
Alles was die Gebühr bezahlt ist eine valide Transaktion und gleichberechtigt, egal, wie ich oder jemand anders das findet.

Kannst du das mal erläutern? Ich sehe es einfach so, dass sich um 99% aller Altcoins kein Angreifer interessiert.
Ethereum bekommt sicher auch ein bisschen was ab.
Wenn man Geld verdienen will mit fallenden Kursen und das durch Angriffe provizieren will, dann lohnt sich das wohl da, wo es eine große Marktkapitalisierung und einfache Angriffsmöglichkeiten gibt.

Es gibt ja schon zentralisiertes Offchain Coinbase und Unocoin in Indien.
Ich denke schon, dass wir in einem Jahr einiges auch dezentral an offchain haben könnten.
Es müssen ja nur die 20% der User, welche 80% der Transaktionen durchführen einen Teil offchain um massiv Kapazität freizugeben.

Edit:
Mir ist Segwit vor allem wichtig, da man nun selbst entscheiden kann, ob seine Transaktion Malleable ist oder nicht.
Das brauchen wir langfristig so oder so um mit anderen Kryptowährungen mitzuhalten und ist wirklich ein schwerer Designfehler im Original Code von Satoshi

Und warum soll Schnorr nicht den Platz erhöhen? Bei Schnorr hilft doch nur bei Signaturen - und gerade da setzt doch Segwit an.
MAST verringert den Platz, den Scripts mit UND bzw. ODER Bedingungen brauchen, zum Beispiel bei Lightning Network - und erhöht die Privatsphäre, da nur der Teil des Skripts veröffentlicht werden muss, der tatsächlich ausgeführt wird.

Wir haben trotzdem keine Vergleichbare Situation in der wir das ausprobieren könnten.
Stell dir mal vor jemand, der EC scheiße findet will unbedingt beweisen, dass spammen möglich ist - mir fallen da eine ganze Reihe an Leuten ein.
Das heißt die Blöcke werden relativ schnell voll sein.

Zudem ist Bitcoin immer noch mit Abstand die sicherste nicht veränderbare Blockchain, das heißt es ist interessant darin seine Daten permanent zu speichern - je günstiger es ist, desto größer ist der Bedarf.

Deswegen ist leider der natürliche Zustand einer begehrten Blockchain, dass die Blöcke relativ schnell voll sein werden.
Ich stimme dir zu, dass die aktuellen Blöcke zu klein sind.

Es geht jetzt zunächst darum den Sweet-Spot zu finden und zu gucken, wie man den Blockspace mit weiteren Verbesserungen (MAST, Schnorr) und mit Off-Chain Lösungen hebeln kann.

Segwit2x schafft uns erstmal genug Zeit um LN auszurollen und um die Verbesserungen einzuführen, ohne das wir die Dezentralität von Bitcoin gefährden müssen.

Solange das nicht gescheitert ist sehe ich einfach 0 Grund so ein extrem risikoreiches Experiment wie EC durchzuführen.
Danach können wir immer noch schauen, wie wir weiter vorgehen.
Sprich: Extension Blocks, Sidechains (Rootstock mit Lumino), Mimblewimble und Kombinationen aus dem Ganzen.

Ich stell mal eine Gegenhypothese:
Miner blocken Segwit und LN, weil Sie Angst haben, dass dies reichen könnte

Edit:
Das ist absolut nicht der Fall.
Ein Client, der nicht Extension-Blocks auswertet kann das trotzdem sicherstellen.

Die Bitcoins für die Sich der Client interessiert verlassen ja nie den Haupt-Block.
Von daher kann er sehen, dass er im Haupt-Block seine Bitcoins erhält und zwar aus dem Haupt-Block.

Was da alles an anderen Dingen im Extension-Block passiert muss den Client nicht unbedingt interessieren - Ein Client der den Extension-Block auswertet sieht dann die Transaktion im Extension-Block und im Haupt-Block.

Der Vorfall kann übrigens nicht passieren den du beschreibst.

Zunächst einmal gilt das nur für die Native-Segwit TX. Die sind im Sinne von alten Clients Non-Std. TX.
Nested-P2SH-Segwit Inputs sollten überhaupt kein Problem darstellen.

Und Achtung: Genau lesen: Segwit verwendet keinen generischen "anyone can spend" sondern aus Sicht von alten Nodes (10% aller Full Nodes) einen speziellen "anyone can spend" Bitcoin Script.

Die Konstruktion wird dann Witness-Program genannt.

Historisch sind nach der Klassifizierung übrigens alle Bitcoin Scripts "anyone can spend", wegen des natürlich behobenen OP_RETURN bugs.

Natürlich ist das ganze rückwärtskompatibel, da der Bitcoin-Script von den alten Nodes auch verarbeitet wird - im Script wird aber keine Signatur gefordert, sondern nur Daten gepusht.

Sobald die TX in einen Block aufgenommen wurde wird die TX auch auf einem alten SPV Node angezeigt.

Bei Ext.Blocks liegst du allerdings falsch ->Die Resolution TX ist eine ganz normale TX, ggf. wird es eine Segwit-Tx, falls Segwit im Hauptblock aktiv ist, wird allerdings wahrscheinlich 100 Blöcke Cooldown haben. Kann man natürlich auch anders konstruieren - ggf. wird die auch non-std, ggf. allerdings tatsächlich komplett ohne Signatur. Edit: Bcoin schlägt OP_TRUE vor. Das Design ist ja so, dass die Signatur im Extension Block normal ist und andere Full Nodes und die Miner die Absicherung übernehmen für Nodes, die Extension Blocks nicht unterstützen wollen / können.

Und was gerade etwas untergeht und ich sehr wichtig finde:
Keiner zwingt einen schlechte Software zu verwenden.
Was hält einen User davon ab Segwit kompatible Software zu verwenden?

Edit:
Also nur 80% aller aktuellen Full-Nodes werden das überprüfen - reicht das nicht?
Und wenn Segwit aktiv ist, steigt das sicherlich schnell auf 95++%.

Jawohl - hat Spaß gemacht.
Ich hoffe, das ich beim nächsten Mal wieder Zeit habe.

Ich meine vor allem Transaktionen sobald diese noch nicht bestätigt wurden.
Bei denen ist es egal, ob man die Signatur überprüft, weil man nicht prüfen kann, ob die Bitcoins echt sind als SPV Node.

Und wenn es bereits in einen Block eingebaut wurde, dann ist das Sicherheitskonzept eines SPV Nodes ja sowieso der längsten Kette zu vertrauen, also muss man es auch da nicht überprüfen, weil man sonst keine Möglichkeit hätte eine andere Chain zu finden.

Segwit als Hard Fork anstelle einer Blocksize Erhöhung ist wirklich eine dumme Idee


Ehrlich gesagt war ich eine Zeitlang für BU - kannst in meiner Posthistory sehen - sind ein paar englische Posts - ging da auch um LN. Und der Auslöser war, dass die Propaganda von /r/bitcoin hat praktisch Abneigung gegenüber Core/Segwit erzeugt hat, also müsse BU ja das bessere sein. Nachdem ich mich aber mehr mit der Technik und den Zusammenhängen auseinandergesetzt habe bin ich aber mittlerweile absolut vom Gegenteil überzeugt. Also da hängt deine Argumentation mit der Propaganda.

Würde mich freuen, wenn mir wer eine PN schreibt, auf wessen Namen der Tisch reserviert ist / wie ich euch erkenne.

Grüße

Siehe noch mein Edit 2 vom letzten Beitrag:
Nein mir ist kein Fall bekannt.
Bleibt trotzdem dabei, dass man derzeit praktisch keinen Sicherheitsgewinn als SPV Node hat, wenn man die Signatur überprüft.

Das Problem wird leider größer, wenn wir einen Weg gehen, wo noch weniger Leute Anregungen haben Full Nodes laufen zu lassen.
Zudem ist die Kommunikation mit den SPV Nodes ist nicht kryptografisch abgesichert, also anfällig für MITM Angriffe - wie sollte man das auch absichern - dann würden wir wieder bei einem Vertrauens basierten Ansatz, wie bei https landen, den Bitcoin ja ersetzt.

Praktisch ist das also nur eine Frage der Zeit, bis sowas angegriffen wird.

Das einzige, was hilft ist, dass man einfach auf genug Bestätigungen für seine Transaktion wartet.

Das sind für mich einfach Punkte die Zeigen, wie wichtig es ist, dass möglichst viele Leute Full Nodes laufen lassen, damit wir nicht wieder bei einem Vertrauens basierten System landen.

Das ist so etwas zu kurz gefasst - Auch SPV Nodes folgen der aus ihrer Sicht validen längsten Chain.
Aus Sicht mancher SPV Clients ist ein Block Size Hard Fork nicht mal ein Fork, wenn Sie diese Regel nicht beachten (sogar nicht mal ein Soft Fork).
Es gibt aber eben auch viele Thin Clients, die auf eine feste Client / Server Architektur aufbauen, da ist es dann wieder vorbei mit dem Hard Fork, da für den Server das ein Hard Fork wäre, dem er nicht folgt.

Ja - Bei Electrum wählt er automatisch den Server mit der längsten Blockchain, egal ob die nun ungültig ist oder nicht, es wird nur der PoW überprüft - dazu darf das Headerformat natürlich nicht mit einem Hard Fork verändert werden.

Das trifft nur auf Clients mit alter Codebase wie BU zu - Core braucht in der Standard-Einstellung nie mehr als 300 MB für den Mempool.
Ich kann da nur wiederholen - BIP148 ist meiner Meinung zu aggressiv und kein normaler UASF - BIP149 als UASF erzeugt keinen Chain Split.
Ich hab mich mittlerweile mit Segwit2x angefreundet, aber BU ist für mich ein mit offenen Augen ins Verderben rennen.
Dann benutze ich lieber wieder Euro, Gold und Aktien oder eine andere Kryptowährung.

Ja, wenn man seinen SPV nicht updated.
Das Problem ist aber als SPV Node teilweise egal, da man als SPV-Node sowieso nicht vor Double-Spends geschützt ist, ohne dass die Blockchain verlängert wurde mit neuen Blöcken, da man überhaupt nicht mitbekommt, dass ein Double-Spend versucht wird.
Auch kann man als SPV Node überhaupt nicht feststellen, ob die Bitcoins, die man erhält überhaupt echt sind - von daher bringt das verifizieren der Transaktion auch nichts. Man kann ja auch eine echte Signatur zu falschen Bitcoins haben.

Edit:
Bin mir nicht ganz sicher, ob das stimmt mit den gefälschten Bitcoins - Die Double Spend Problematik ist jedenfalls Real - ggf. kann man den Outpoint allerdings beweisen indem man einen Pruned Merkle Tree vom entsprechenden Block beim Full-Node anfordert, der beweist, dass der Output existiert - allerdings kann man so nicht beweisen, dass dieser nicht bereits ausgegeben wurde - das müsste der Full-Node dann einem als Fraud-Proof zusenden - soweit ich weiß haben wir aber keine Fraud-Proofs.
Edit2:
https://en.bitcoin.it/wiki/Thin_Client_Security
Ja - es ist praktisch nutzlos als Thin Client die Signatur zu überprüfen, solange es kein Unused Output Tree und Fraud Proofs gibt, solange man nicht sicher weiß, dass die Full Nodes zu denen man verbunden ist 100% vertrauenswürdig sind. Und falls diese vertrauenswürdig sind, werden diese bereits die Signatur für einen überprüft haben (egal ob Segwit oder nicht), sonst hätten diese die Tx nicht weitergeleitet.


Das ist ansich richtig, aber du vertraust hier auf zufälliges verhalten - mal wird es funktionieren mal nicht.
Denn das Problem ist ja, dass es zufällig ist, ob man überhaupt auf der Chain landet, oder bei anderen Clients die nicht der Blockchain folgen.
Bei der aktuellen sehr geringen anzahl an BU-Nodes ist es sogar sehr wahrscheinlich, dass man eben nicht dem Hard Fork folgt, egal wieviel Hash Power der hat.


Dann kommt es eben zum Chain Split - egal ob das jetzt ein zweiter Hard Fork oder Soft Fork oder was auch immer wird.
Selbst 100% der Hash Power reichen nicht aus, wenn ein nicht unerheblicher Teil das Wesen des Bitcoins als verraten sieht.

Es gibt nun mal nicht die perfekte Lösung um alle glücklich zu machen:
Die Alternative 2 Blockchains - 1 für Big Blocker und 1 für Small Blocker macht das gleiche, außer das man zusätzlich noch mit unterschiedlichen Währungen (BTC-A, BTC-B) arbeitet.

Ich weiß nicht, was du meinst?
Auch für SPV Nodes ist das ein Soft Fork:
Eine SPV Node, die kein Segwit/Ext-Block unterstützt kann sich zu einer beliebigen Full-Node (also mit Segwit/Ext-Block oder ohne) verbinden und kann auch von Segwit oder Ext-Block Adressen Bitcoins normal empfangen. Außerdem kann es an Nested-P2SH-Segwit Adressen senden. Senden an Ext-Block Adressen und senden an Native-Segwit-Adressen geht allerdings nicht, außer mit einer Raw-Tx.

Eine SPV Node, die Segwit/Ext-Block direkt unterstützt, muss beim verbinden zu einer Full-Node darauf achten, dass diese den gewünschten Service (Segwit/Ext-Block) eben zur Verfügung stellt. Die Node kann dann in einer beliebigen Kombination von Legacy, Segwit, Ext-Block Adressen empfangen und an diese senden.

Vergleich Hard Fork, Evil Soft Fork und Chain Split:
Eine SPV-Node kann nur innerhalb ihrer Chain senden und empfangen. Zudem muss die SPV-Node darauf achten, dass sie überhaupt zu einem Node verbindet, welche auf der richtigen Chain ist. Soweit ich weiß kann man das nicht so einfach erkennen, sondern muss erstmal komplett alle Header runterladen und verarbeiten und dem SPV Node zudem beibringen, wie es die Chains unterscheiden kann.
Wenn das Transaktionsformat oder die Header verändert werden funktioniert die SPV Node nicht mehr.

Also:
Soft Fork ohne Chain Split -> SPV Node funktioniert wie erwartet ohne weitere Anpassungen -> Update der SPV Node schaltet neue Funktionen frei

Hard Fork, Evil Soft Fork oder Chain Split -> SPV Node funktioniert nicht, oder landet auf einer zufälligen Chain -> Update der SPV Node unbedingt erforderlich

Edit:
Das Transaktionsformat von Segwit und Ext-Blocks ist rückwärtskompatibel, geht ja nicht anders, da es ein Soft Fork ist

Lustig - das Nodes ohne Ext. Blocks, die Ext. Blocks nicht verarbeiten müssen, ist was ich so toll finde an Ext. Blocks.

Das ist zumindest auch die einzige mir bekannte Variante, wie es überhaupt zu schaffen wäre Small-Blocker und Big-Blocker gleichzeitig in einem Netzwerk zufrieden zu stellen.

Edit: Und mit SPV Nodes ist es ja sowieso problemlos möglich die Extension Blocks zu nutzen