Topic: Re: Der Aktuelle Kursverlauf blockgrösse - page 47. (Read 185830 times)

Genau, sehe ich auch so. So unkompliziert wie möglich, so dass es so viele Leute wie möglich verstehen und verifizieren können.


Für mich sind wir schon seit einigen Monaten auf dem Kontinten der "verpassten Chancen". Mich würde aber interessieren, welche Chance wir deiner Meinung nach mit 2MB + SW verpassen werden?


Manchmal wird SegWit als 2MB Softfork bezeichnet. Das ist falsch, da SegWit eher eine 1,5 MB Size mit DoS-Angriffsfläche von 4mb ist. Und darüber hinaus eine Menge andere Dinge als Blocksize-Erhöhung macht.

Extension Blocks ist die andere Idee von 2mb Softfork. Daran wird gerade gearbeitet, siehe bcoin, und vermutlich wird das der Ausweg werden, wenn wir ans Limit von 2MB+SW knallen bzw. wird schon vorher eingerichtet, um eine Art Sidechain für billige Massentransaktionen zu werden.

Es wäre logisch so wenig wie möglich in den Hard-Fork zu packen, also viel alten Code zu entfernen und wenig neuen Code einzubauen. Das senkt das Risiko und erhöht die Testabdeckung, da es weniger Variationen zu testen gibt.

Von mir aus kann man auch segwit als Soft-Fork und 2MB als Hard-Fork machen, wenn alle das tatsächlich wollen. Das würde ich für mich dann eben unter verpasste Chance ablegen.

Falls man generell nichts ändern möchte - was spricht nochmal gegen 2MB als Soft-Fork?!

Ich möchte jetzt nicht überdramatisieren. Aber sorry. Seit 2014 haben Leute gesagt "Erhöht die Blocksize", und es ist nichts passiert. Core hätte noch 2015, vielleicht auch noch 2016, eine Hardfork in xx Monaten ankündigen können und da all die tollen Dinge reinpacken. Haben sie aber nicht gemacht. Jetzt haben die Miner und die Wirtschaft die Geduld verloren und machen ohne Core eine Mimimal-Hardfork, um das Blocksize-Problem zu fixen.

Sowieso: Es ist war an sich logisch, in eine Hardfork so viel reinzupacken wie möglich, wenn man sie schon macht. Andererseits aber bedeutet das, dass der Code für die Hardfork und diese selbst komplexer wird, dass es mehr Möglichkeiten gibt, wie etwas schief geht, dass es mehr Kontroversen geben kann, dass es schwieriger wird, entstandene Schäden zu beheben, und dass die Umstellung der Clients und der darum herum gebauten Software eventuell schwieriger wird. Wenn ich es mir so überlege, sollte man es vermeiden, allzu viel in eine HF zu stecken.

Im Grunde richtig aber imo nicht realistisch. Dann gehen die ganzen Diskussionen wieder von vorne los und wir haben in 10 Jahren noch keine Lösung. Denn ich bin mir ziemlich sicher irgendwer hat was dagegen und gründet eine Bewegung um zu zeigen, dass sein Ego das größte ist.

Ist es nicht. Wer mit "zu spät" argumentiert will andere nur grundlos in die Ecke drängen. Wenn man sowieso eine Revolution macht, dann wirft man Altlasten über Bord und zieht diese nicht wie beim evolutionären Ansatz hinter sich her. Wenn man an einem Geldsystem herumschraubt, dann macht man das unter den gegebenen Bedingungen (Hard-Fork / Soft-Fork) richtig - oder gar nicht.

Also entweder alles per Soft-Fork oder aber ein Hard-Fork ohne die ganzen Altlasten.

Meine Meinung.

Wie gesagt: Wenn Unternehmen und Miner einverstanden sind, ist ein Chainsplit vermutlich nicht weiter relevant, egal wie man es macht. Die Schwierigkeit beim Bitcoin-Mining ist mittlerweile so astronomisch ...

An sich fände ich es auch schön, wenn man all die Dinge macht, für die man eine Hardfork braucht. UTXO committments zum Beispiel wären geil. Aber das hätte man vor 2-3 Jahren planen sollen. Heute ist es dafür zu spät.

Wenn weniger als 10 Prozent der Miner mitmachen, gibt es keine Chainsplit.

Soweit ich es gehört habe, ja, die allermeisten sind mit SW + 2 MB einverstanden. Du nicht?

Beantwortet alles aber meine Frage nicht: Warum unbedingt ein ChainSplit?

Doch das scheint zu gehen. Irgendwo im Development Bereich hat vor kurzem jemand eine Lösung, basierend auf den erweiterten segwit Transaktionen, skizziert. Damit wären 2MB per Soft-Fork möglich.

Allerdings würden die 2MB nur für segwit Transaktionen gelten. Ist aber auch klar, da die alten Knoten davon nichts wissen können. Ausserdem wäre es sinnvoll, da nur für die segwit Transaktionen das Problem mit dem quadratischen Aufwand zur Hashberechnung gelöst ist.

Möchte man segwit + 2MB per Hard-Fork, wäre die von Gavin vorgeschlagene segwit Umsetzung sinnvoller, da dort das Block-Format deutlich vereinfacht wird. Daneben könnte (sollte!) man mit einem Hard-Fork gleich noch ein paar andere Sachen geradeziehen. In diesem Zug könnte man dann gleich die bisherigen Transaktionsformate über Bord werfen. Warum Altlasten mitschleppen, wenn sowieso alle zum Stichtag umstellen müssen?! Die bisherigen Soft-Fork vorschläge sind nur unter der Annahme sinnvoll, dass die alten Knoten ohne Änderung weiterarbeiten können. Peilt man einen Hard-Fork an, muss man das gesammte System vereinfachen. Alles andere wäre grober Unfug.

Wie willst du ohne Hardfork 2MB machen? Nach meinem Verständnis geht das nicht.

Ach, ist das so?

Kannst du mir erklären, warum dir eine UASF so wichtig ist?

Es gibt jetzt ein Agreement, das von genügend Minern und Unternehmen getragen wird, um OHNE split mehr Kapazität + SegWit zu schaffen, und so weit ich es verstanden habe, sind so gut wie alle Small Blocker einverstanden mit SegWit+2MB.

Die ganze Zeit hieß es, eine Hard Fork sei schlecht, weil sie zu einem Chain split führen kann. Nun haben wir die Möglichkeit, die Hard Fork ohne Chain splitt zu schaffen, und die UASF Fans versuchen auf Teufel komm' raus SegWit auf eine Weise zu aktivieren, die garantiert zum Chain Split führt.

Warum? Nur aus Prinzip, weil "Jihan böse" + "User haben die Hosen an"? Also, um einen Punkt zu machen?

Verstanden. Wenn SegWit entweder (4) ab 80% oder SegWit(1) ab 95% offiziell durch ist, ist es durch. Danke.

Dann minen sie ungültige Blöcke und verdienen nichts.

Der wird doch aber direkt mit dem Hardfork auf 2MB verbunden sein?
Also würde es ein Hardfork?
Und ob die Miner nach einem 2MB Hardfork incl. Segwit. Später Segwit weiter machen ist auch nicht garantiert, oder?

Ich denke, mit dem BIP wird lediglich Bitcoin Core kompatibel gemacht mit dem ersten Teil des New York Agreements.

Barry Silbert wird sicher derzeit versuchen, ein neues Dev-Team aufzustellen, das den 2 MB Hardfrok codiert (so trivial ist das nämlich nicht),  und vermutlich auch im Weiteren dann die Geschicke von Bitcoin leiten soll. Bei dem New York agreement war mit Gavin Andresen nur 1 ehemaligen Bitcoin Developer beteiligt.

Die Stille zu dem Thema ist ja geradezu ohrenbetäubend.

Soweit ich mich erinnere, gibt es auch einige anderen Bugs/Unschönheiten im Bitcoin Code, die man nur durch einen Hardfork beseitigen kann. Es wäre daher wünschenwert, wenn da sinnvoll zusammengearbeitet wird mit einigen erfahrenen Core developpern.

Aber das wünschenswerte passiert beim Bitcoin schon lange nicht mehr, also machen wir uns mal alle schön auf die nächsten Enttäuschungen gefasst.

Wer ist denn James Hilliard? Er ist ja der Autor von BIP91.
Mir sagt der Name im Moment gar nichts. Schon mal gut das es ein Softfork ist.

BIP91 für MASF von SegWit mit 80% und versionsbit 4 liegt vor. am 1. Juni 2017 könnte es laut definition losgehen.

https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki

Core-Entwickler Eric Lombrozo geht unter die bösen Verräter, die statt dem Chainsplit noch einen Konsens verfolgen. So wie ich es interpretiere, will er versuchen, aus Barry Silbert's Agreement was brauchbares zu machen, dem auch die Core-Leute zustimmen können.

Auf dieser Seite ist unten eine Erläuterung, wie Exchanges sowohl BIP-148 Bitcoin als auch Legacy-Bitcoin handeln können.
Es ist leider ziemlich kompliziert:
https://www.weusecoins.com/uasf-guide/
Bitte selbst den Link durchlesen, ich möchte das nicht alles hier reinkopieren.
Für große Exchanges ist so etwas vom Aufwand her wohl machbar, aber für die Nutzer schwer verständlich.

Es hätte natürlich für die Exchanges den Vorteil, dass sie sich selbst keinem Risiko aussetzen. Eine Exchange, die einen Alleingang macht und komplett auf BIP-148 umstellt, geht zwar auch nicht unbedingt Pleite im Fall eines Mißerfolgs, aber sie verliert den Großteil ihrer Kunden, sowie alle ihre Coins auf der BIP-148 Chain, die nicht Kundeneinlagen waren. Die Coins der Kunden verliert sie natürlich auch, aber die muss sie ja nicht erstatten. Gleiches gilt natürlich für eine Exchange, die bei der UASF-Fork nicht mitmacht, in dem Fall, dass die UASF erfolgreich ist.

Ideal wäre es, wenn sich mehrere Exchanges absprechen und gemeinsam auf BIP-148 umstellen. Über entsprechende einklagbare Verträge mit verbindlichen Schadenssummen könnten sie sich gegenseitig versichern, dass sie sich nicht gegenseitig im Regen stehen lässen.

Bleibt zu hoffen, dass der Crash möglichst heftig wird, denn desto besser stehen die Chancen für die UASF.

zu erklärung: Phil Potter gehört zu BitFinex.

Gerade gesehen



Wie funktioniert das genau?
Damit verpflichten sie sich doch rechtlich, dann ab 1. August den BIP148 tatsächlich als Altcoin zu listen, mit Withdraw-Möglichkeit und all den oben genannten Problemen.
Können ja wohl dann schlecht sagen, das Token ist wertlos, weil es auf keiner Exchange ist, und einfach das Geld einsacken.

Und wie ist das mit dem BU-Token, kennt sich da jemand aus?