@mezzo
Ich stimme dir weitgehend zu.

Es gibt zudem Übergangslösungen wie Edge-Nodes, die auch Adam Back immer wieder für Segwit angepriesen hat.
Das funktioniert exzellent für Opt-In Soft Forks (Segwit, Extension Blocks), ohne das man seine eigene Software anpassen muss.
Evil Soft Forks (wie ich kürzlich einen beschrieben habe) und Hard Forks können das allerdings unmöglich machen.

Und dann gibt es eben Hard Forks, welche schwieriger zu adaptieren sind und dann gibt es welche die einfacher in die eigene Lösung einzubauen sind.

2 MB gehört sicher zu den einfacheren, aber auch da muss man dann selbst ein Testnet aufziehen. Software entwickelt gerne unvorhergesehene Seiteneffekte, die man überhaupt nicht erwartet hat - und wenn wir Bitcoin nicht zur Trashcoin werden lassen wollen brauch das eben einige Monate, damit alle Teilnehmer eine realistische Chance haben das zu implementieren und sauber zu testen.

Segwit ist zwar bei simpler technischer Betrachtung ein weitaus größere Änderung als ein 2 MB Hard Fork, allerdings kann man sich davon eben komplett abkapseln indem man so eine Edge-Node betreibt, während man bei 2 MB gezwungen wird seine eigene Software anzupassen und komplett neu zu testen.

Der Medium Artikel von Jeff Garzik lässt mich mal hoffen, dass Segwit dann doch über BIP91 und somit kompatibel zu unseren aktuellen Clients und bei schneller Einführung sogar zu den BIP-148 UASF Clients ist.

Der 2 MB Hard Fork lässt sich sowieso nicht erzwingen, wäre momentan aber nicht abgeneigt dem zu folgen.

Finde es gut, dass das ganze wieder etwas offener abläuft und wir nicht mit einem fertigen Backroom Deal abgespeist werden.

Quelle:
https://medium.com/@jgarzik/a-personal-note-to-the-bitcoin-community-c24aa0821ab
https://github.com/btc1/bitcoin/pull/6#issuecomment-305032004

Was ich da technisch beschrieben habe beweist praktisch, dass die den Hard Fork nur um den Hard Fork willen haben wollen, aber es überhaupt nicht notwendig ist um den Speicherplatz für nicht Witness Daten zu schaffen.

Bei so einem Soft Fork müssten eben alle updaten - es werden sogar alle gezwungen zum updaten wenn mehr als 50% Hashing Power / Miner den von mir beschriebenen Soft Fork anwenden würden, den dieser Soft Fork wäre nur pseudo-rückwärtskompatibel.

Dafür würde man technisch sicherstellen können, dass Segwit + 2 MB gleichzeitig kommt.

Und schlechter als bei einem Hard Fork ist man auch nicht, da müssten auch alle updaten.

SPV Clients müssten allerdings zusätzlich die Coinbase TX auswerten (müssen die aber sowieso bei Segwit).

Um sich dagegen zu wehren müsste man einen ziemlich ausgefuxten Soft Fork oder Hard Fork durchführen. Alternativ geht es natürlich den  den 1. Block der den zuvor beschriebenen Soft Fork anwendet explizit hart kodiert im Programmcode als invalid zu markieren.

Unter der Annahme, dass die Mehrheit für Segwit+2MB ist, bzw. das als Kompromiss akzeptiert, wäre das Verfahren allerdings tragbar.
Ansonsten erzeugt man mit so einem "bösen" Soft Fork natürlich schnell einen Krieg (nicht, dass wir sowas ähnliches schon praktisch haben).

@Greshamsches Geld, Synthetic Fork oder sowas:

Man könnte sich den HF ja auch schenken und das gleiche als Soft Fork machen, ähnlich wie bei Segwit nur ein bisschen extremer:

Coinbase TX bekommt ein Merkle Tree Commitment für alle Transaktionen.
2 MB Block ist nicht sichtbar für alte Clients - die sehen im Block nur die Coinbase TX.
Der Block darf neben der Coinbase TX keine weitere TX haben die sichtbar für alte Clients ist.

Man benutzt weiterhin das ganz normale UTXO (im Gegensatz zu Extension Blocks) und et voilà 2 MB Block Size ohne HF.
Automatisch Wipe-Out protection inklusive, Segwit gleichzeitig aktiv.

Dieses ewige bestehen auf HF macht mich etwas verrückt - da sitzen doch so viele schlaue Leute  

Soweit ich weiß ist der aktuelle Entwurf so, dass Segwit mit den 80% aktiviert wird und auch die 80% für die Aktivierung des HFs zuständig sind - im "schlimmsten" Fall kommt also beides gleichzeitig.

Wenn man das ganze ein bisschen absichern will könnte man den HF auch als Synthetic Fork durchführen - hab ich aktuell nichts mehr zu gelesen. Warum eigentlich?  

Meiner Meinung nach ist das updaten müssen schon absichtlich.
Ich meine der Mechanismus über BIP91 bzw. BIP148 ist ja bekannt und liegt sogar als Quellcode vor.

Version bit 4 könnte einfach dafür sorgen, dass die Aktivierung über Bit 1 (Standard Segwit BIP141) erzwungen wird (also praktisch wie BIP148, aber ohne Flag Day, sondern Startzeitpunkt eben 2 Wochen, nachdem die 80% erreicht wurden).
Der einzige Nachteil den man dadurch hätte, wäre das Segwit 2 Wochen später käme, weil eben 2 Aktivierungen erfolgen.

Die Big Blocker fürchten natürlich das zu dem Zeitpunkt wo der Hard Fork dann erfolgen soll der Core Client aufgrund seiner Dominanz verhindert, weil viele zu dem Zeitpunkt dann der Meinung sein werden, dass man den 2 MB Hard Fork nicht wirklich braucht.

Ob man damit jetzt aber wirklich weiter kommt? Core könnte auch einen Client der das neue "Frankensegwit" (sorry aber ich finde den Namen so lustig) unterstützt veröffentlichen, ohne den Hard Fork einzubauen.

Würde mich zumindest nicht wundern.

Erst wenn der 2 MB Hard Fork Tag durch ist, wissen wir wirklich was Sache ist.

Immerhin kommt Segwit zuerst, was ich für vernünftig halte, da die Worst-Case und Avg-Case CPU-Laufzeit für einen Segwit Block wesentlich besser sein werden, als ein einfacher 2 MB Hard Fork Block - und so zudem bessere Aussicht auf neue Entwicklungen für Bitcoin Funktionalitäten besteht (Schnorr, LN & Co.).

Um mal etwas zu provozieren:
Also ich lese das Agreement so, dass man sich praktisch nur auf den 2MB Hardfork geeinigt hat.

Segwit wird nur aktiviert, wenn es 80% der Miner wollen - Roger Ver hat sich auch schon so geäußert, soweit ich weiß.

Ich sollte es auch schaffen.
Freue mich mal an einem Stammtisch teilzunehmen.

@CB
Ich antworte dir später ausführlich.

Kurz zu UTXO Commitments.
Praktisch lässt sich das einfach als Soft Fork lösen, genauso wie das bei Segwit gemacht wurde indem man das in einen Output der Coinbase Transaction speichert (die Transaktion, welche die neuen BTC und Gebühren an den Miner auszahlt).

Es ließe sich aber sogar ohne Soft Fork einbauen, dann ist es eben nur Information und es wird nicht erzwungen, dass der Block falsch ist, wenn das UTXO Commitment fehlt oder fehlerhaft ist.

Einige Pools speichern ja jetzt schon Daten mit dem Mechanismus in der Coinbase Transaction.

Edit:
Link zu einer aktuellen Mailingliste Diskussion
http://bitcoin-development.narkive.com/UWXb6P0y/rolling-utxo-set-hashes

Does anyone know if ASICBoost is addressed?
Will the segwit be a HF Segwit without OP_RETURN commitment?
So - will covert ASICBoost continue to work as is?

I'm not conviced this is a fair compromise.

Naja - also was stört mich daran? Das ich als Nutzer kein Mitspracherecht mehr habe, außer eben die spezielle Blockchain nicht zu benutzen.
Die Miner handeln eben im Interesse der Miner. Manchmal stimmt das eben mit dem Interesse eines durchschnittlichen Nutzers zusammen (Segwit / LN) und manchmal eben nicht.
Miner sind meiner Ansicht nach keine Feinde, aber man sollte sie nicht einfach machen lassen, was sie wollen.

Das sehe ich anders - Im Szenario EC ist das sehr wahrscheinlich, aber mit kleineren Blöcken nicht notwendig.
Zum Beispiel kommen da ja noch die UTXO-Commitments, mit denen man dann rückwärts syncen könnte.
Mit Segwit+2MB, also effektiv irgendwo zwischen 5-6 MB irgendwann mal pro Block reicht so eine 4 TB Festplatte ja doch einige Jahre.

Zum anderen ist das finde ich wieder ein Argument für Extension Blocks.
Bcoin hat aktuell auch eine Deaktivierung vorgesehen.
Das heißt man kann nachdem der spezielle Extension Block deaktiviert wurde sämtliche Daten aus der Extension Blockchain wegschmeißen.
Optimaler Weise hat man natürlich bereits einen neuen Extension Block vorher eingeführt, der dann die Aufgabe von diesem übernimmt.


Ich sehe nicht, dass die Organisation im BIP148 UASF Szenario reibungslos laufen würde, sonst wäre es ja wohl kaum so kontrovers. Keiner weiß, ob das jetzt wirklich stattfindet, oder wie das tatsächlich abliefe.

Das BIP148 Szenario ist einfacher, das heißt entweder unterstütz man das oder eben nicht. Und wenn es dann scheitert, dann ist man nicht schlechter als der status quo.

Bei einem EC Szenario gibt es sehr viele Unterschiedliche Wahlmöglichkeiten. Das macht das ganze schon schwerer gemeinsam Druck aufzubauen. Und was passiert, wenn das eigene EB Setting überstimmt wurde? Dann muss man eben aufgeben und trotzdem den größeren Blöcken folgen und hat nicht mehr den Status quo.

Chain Splits sind immer unglücklich - ich finde das mit BU auch kein No-Go. Die Idee, die viele bei BU haben (z.B. Peter Rizun) und die Architektur (Split am Anfang der Diff Period) ist allerdings so gewählt, dass die Kette mit der geringeren Hashrate die maximalen Nachteile hat (Kapazität für Transaktionen/s) und wird wahrscheinlich deswegen oft als Angriff gesehen.

Außerdem geht hier die Aktion von den Minern aus, während BIP148 die Aktion von den Usern ausgeht, weswegen es wahrscheinlich bei einigen Usern beliebter ist, weil Ihnen hier eine stärkere Mitgestaltungsmöglichkeit geboten wird. Ein Miner sieht das vielleicht anders.
Es ist beides suboptimal.

Deswegen bin ich ja auch weiterhin nicht wirklich überzeugt von BIP148.

So wie ich das sehe, sind die Miner, welche für BU signalisieren überwiegend der Meinung, dass Sie festlegen sollten, was die richtige Blockgröße ist.

Ein Kriterium wird sicherlich sein, was ande Nodes als AD setzen.
Da das aber leicht ein Sybill-Angriff darauf erfolgen kann taugt das wohl kaum.

Das heißt es wird über irgendwelche Backroom-Deals festgelegt, welche Exchange oder Dienstleister welche Blockgröße für richtig hält.

Außerdem gehe ich sowieso davon aus, dass in einem EC Szenario die allermeisten Knoten auf SPV wechseln werden, da kann man dann sowieso nichts mehr einstellen.

Niemand wird in einem EC Szenario als normaler Nutzer genügend andere Nutzer finden können um ökonomischen Druck auf die Miner auszuüben.

Genau die Kette von einem BIP148 Client bleibt dann in dem Fall stehen, wenn alle Miner weiter auf der Legacy Chain arbeiten.
Der Witz ist ja auch, dass für den BIP148 Client die Zeit stehen bleibt, denn es gilt nicht die aktuelle Systemzeit, sondern die Median Zeit aus den letzten empfangenen Blöcken.

Hier der BIP148 patch:

Siehe mein Edit oben - technisch stimmt das zwar, aber ökonomisch und politisch kann ich mir das nicht ansatzweise vorstellen, dass das ähnlich funktionieren würde, da keine ausreichende Koordinierung stattfinden würde.

Edit:
Wenn die Legacy Chains Segwit Blöcke anhängt, dann kann ein BIP148 Client das nie sehen, weil da nach seinen Regeln ein ungültiger Block dazwischen ist - und das wird sich ja auch nie ändern.

Das hatte ich am Anfang auch gedacht zu BU.

Aber je mehr ich darüber nachgedacht habe, desto mehr bin ich zu der Erkenntnis gekommen, dass es für die Nutzer einfach nicht funktioniert.
Die Koordination unter Nutzern würde so schwierig sein (angenommen BU ist der dominierende Client), dass man als einzelner Nutzer da zwar irgendwas einstellen kann, das tatsächlich aber keine Auswirkung hat, sondern ausschließlich die Miner dann die Aufgabe übernehmen die Blockgröße festzulegen.

Edit:
zum Chain Split: BIP148 in Core macht es nur leichter den RPC Call invalidateblock zu automatisieren.
Bei BU hat es meiner Meinung nach sowieso keine Bedeutung, was man als EB einstellt, abgesehen man nimmt für EB=1 und AD=inf, das was da von Core Trolls als Chain Split Risiko angeprangert wurde existiert meiner Meinung nach nicht, weil das System so nicht mehr funktioniert, wenn man die Macht an die Miner abgegeben hat.

Ich hab ja schon ein paar mal zu BIP148 geschrieben.
Ich bevorzuge aktuell BIP149

Ohne Unterstützung von Minern wird es die Chain nie geben.
Ohne breite Unterstützung von Exchanges wird man schwer ökonomischen Druck ausüben können.

Da es optional ist sehe ich nicht das große Problem darin.

Um mal aufzulisten, was ich für sinnvoll halte und unterstützen würde (absteigende Präferenz, aber nicht untereinander exclusiv):

• Segwit über BIP149
• Extension Blocks, kompatibel zu Segwit BIP141
• Rootstock RSK
• Segwit + 2 MB HF in ~12 Monaten, unter der Vorraussetzung, dass Segwit kompatibel zu Bitcoin Core BIP141 ist, sonst hat man ja kaum einen Vorteil durch Segwit
• BIP148 mit >50% Miner Unterstützung
• Status quo

Alles andere überzeugt mich derzeit nicht

Ich warte da jetzt erstmal ab, was da passiert.
Mir ist noch nicht klar, ob das wirklich durchgeht, ob das wirklich so passiert ist und was der wirkliche Inhalt des Dokuments ist.

Da es ein Hard Fork ist werden die Coins ja sowieso verdoppelt, also kann ich mir das später immer noch überlegen.

Edit:
Ich hatte ja schon vorher geschrieben.
Ich bin zufriden mit Segwit in einem Jahr über BIP149
Solange eben Rootstock

@CB
Naja das ist ja nicht was ich unter Segwit+2MB verstanden hatte.
Alle Clients von Core werden das Segwit aus dem Vorschlag nicht unterstützen.

Und der Hard Fork kommt mir einfach viel zu früh - 12 Monate hätte ich für angemessen gehalten.

Dezentral - so ungefähr wie aktuell

Das mit Charlie Lee war ein bisschen mit Augenzwinkern gemeint.
Während es bei Litecoin eben eine Person gibt, die das ganze steuert und das von der Community akzeptiert ist, ist das ganze Bild bei Bitcoin deutlich unklarer.

Core als Organisation will diese Rolle nicht haben, so wie ich das verstehe, weiß auch nicht, ob sie diese Rolle überhaupt noch einnehmen könnten.
Es gibt wie du schreibst einzelne Entwickler (v. a. Luke-Jr), die Ihre Vision pushen.
BU als Organisation wird von den allermeisten nicht akzeptiert und mittlerweile sehen auch viele die Miner sehr kritisch.

Das Ziel von Bitcoin ist meiner Meinung nach also am ehesten, was die Leute die es benutzen aktuell wollen. Das sind dann Leute die es tatsächlich zum bezahlen nutzen, Spekulanten, Node-Betreiber, Entwickler und Miner. Und zum einen ist das schwer zu erfassen und zum anderen ändert sich das auch noch ständig.
Und des weiteren ist es natürlich schwierig für die Masse sich zu organisieren.

Mein persönliches Ziel für Bitcoin ist auch, dass die Einstiegsmöglichkeiten so dezentral wie möglich bleiben. Segwit passt dazu, Extension Blocks sowieso, Rootstock als Sidechain entlastet das auch noch mal und LN hat zumindest großes Potential.

Bin mal gespannt, wie das Barry Silbert Agreement wirklich aussieht.
https://pastebin.com/VuCYteJh

Falls es das ist, dann überzeugt mich das nicht. Hard Forks bei der aktuellen politischen Lage sind einfach extrem schwierig, auch wenn technisch 2MB aus meiner Sicht kein Problem sind.

Das Problem an jedem Block Size Hard Fork ist auch, dass es eben auch schwieriger wird Widerstand gegen weitere Anhebungen der Blockgröße zu leisten, da viele Leute die für Dezentralisierung arbeiten bereits von Bitcoin auf andere Kryptowährungen (oder einen Bitcoin-Fork) umsteigen. Deswegen gehen viele wahrscheinlich auch so aggressiv dagegen vor, da aus 2 MB leicht 32 MB und mehr werden.

Zahle lieber 50 ct. pro Transaktion auf Layer 1, als das ich darauf angewiesen wäre einen SPV Client zu benutzen.
SPV gerne auf Layer 2.

Falls das nicht sauber durchdacht ist, landen wir leicht bei einem Chain Split - da können die aktuellen Pools noch so viel machen.
Die Anhänger von Luke-Jr und er machen dann eben einen PoW Change.
Seinen eigenen (aktuell nicht erfolgreichen) Bitcoin Client hat er ja sowieso schon seit längerer Zeit.

Steht auch nichts zu ASICBoost drin.

Mal abwarten...

Hatte ich auch schon hier gepostet
Fairerweise muss man dazu aber anmerken, dass die Median-Fee ~4 ct. ist, was dann typisch für einfache Transfers von Guthaben wäre.

Genau nur ein paar Leute, die es technisch absolut drauf haben und dazu noch pragmatisch vorgehen.
Die Eigenschaften gleichzeitig bringt aktuell kein populärer/s Standard-Bitcoin-Client/Entwicklungsteam.

Und achja - es ermöglicht unter anderem "nur" sehr günstige Transaktionen mit der Währung Bitcoin.
Und nebenbei ist es wohl wesentlich effizienter als Ethereum (die EVM).

Das ist der perfekte Anwendungszweck für Rootstock und LTCP.
Wenn der Payment-Channel eben nur 1 € insgesamt als Volumen haben soll, dann ist das eben auf einer auf dem Bitcoin-System aufbauenden Blockchain sehr ineffizient.
Ist sicherlich pragmatisch da Litecoin zu nehmen, weil das mit minimalem Entwicklungsaufwand umgestellt werden kann.

Litecoin (Lee's Vision) hat aber auch nicht das Ziel so dezentral zu sein, wie Bitcoin - deswegen ist da Lee auch etwas anders zu Hard Forks eingestellt.