Warum ist SegWit nicht jetzt schon aktiviert

[shinjikun]

Technisch meine ich verstanden zu haben was SegWit ist, aber trotzdem scheint mir nocht etwas entscheidendes entgangen zu sein.
Eines der Vorteile von SegWit ist ja, dass so gestallte Blöcke von den aktuellen Nodes, als etwas Seltsam anmutende, aber denoch gültige Blöcke erscheinen.
Das alle Blöcke nach diesem Schema aufgebaut werden müssen um die malleability zu fixen und damit 2. Layer zu ermöglichen leuchtet mir ein. Was ich aber nicht verstehe ist, warum nicht jetzt gerade der nächste Miner der ein Block generiert diesen nach Segwit-Schema formt. Der wäre doch gültig. Das ist doch der Witz an SegWit. Er könnte effektiv 4 MB Blöcke generieren und dementsprechend mehr Gebühren einstreichen. Da die Miner nicht so blöd sind und dieses Geld nicht mitnehmen würden scheine ich irgendetwas zu verpassen.

Kann mir jemand helfen?

[1715193436]

1715193436

[1715193436]

1715193436

[1715193436]

1715193436

[1715193436]

1715193436

[1715193436]

1715193436

[1715193436]

1715193436

[shorena]

Technisch meine ich verstanden zu haben was SegWit ist, aber trotzdem scheint mir nocht etwas entscheidendes entgangen zu sein.
Eines der Vorteile von SegWit ist ja, dass so gestallte Blöcke von den aktuellen Nodes, als etwas Seltsam anmutende, aber denoch gültige Blöcke erscheinen.
Das alle Blöcke nach diesem Schema aufgebaut werden müssen um die malleability zu fixen und damit 2. Layer zu ermöglichen leuchtet mir ein. Was ich aber nicht verstehe ist, warum nicht jetzt gerade der nächste Miner der ein Block generiert diesen nach Segwit-Schema formt. Der wäre doch gültig. Das ist doch der Witz an SegWit. Er könnte effektiv 4 MB Blöcke generieren und dementsprechend mehr Gebühren einstreichen. Da die Miner nicht so blöd sind und dieses Geld nicht mitnehmen würden scheine ich irgendetwas zu verpassen.

Kann mir jemand helfen?

SegWit hat eine Aktivierungsschwelle von 95%[1]. Bis die nicht erreicht ist, ist SegWit nicht aktiv und einen solchen Block zu minen ist Geldverschwendung weil ihn niemand akzeptiert. Die Schwelle wurde nicht erreicht (und wird es wohl auch nicht mehr), weil deutlich mehr als 5% Mining Power in der Hand von Menschen ist die SegWit für einen schlechte Idee halten.

[1] http://segwit.co/

[shinjikun]

Die AKtivierungsschwelle von 95% über ca 2 Wochen heißt ja etwas anderes. Wenn dies erreicht ist, ist SegWit Pflicht für alle zukünftigen Blöcke.

Der Witz an SegWit aber ist doch, dass sie schon nach den jetztigen Regeln gültig sind. Deswegen ist es ja auch nur ein Softfork. Und aus diesem Grund, sollte er eben doch von den anderen Minern akzeptiert werden.

[david123]

https://coin.dance/blocks sieht ja auch nicht mehr so rosig aus.
Anscheinend machen F2pool, Slush, Kano nicht mit.. Und so lange das sich nicht ändert,
passiert nichts in Richtung SegWit, oder wie? Dann muss ich so langsam doch in ETH
umschichten 

[shinjikun]

https://coin.dance/blocks sieht ja auch nicht mehr so rosig aus.
Anscheinend machen F2pool, Slush, Kano nicht mit.. Und so lange das sich nicht ändert,
passiert nichts in Richtung SegWit, oder wie? Dann muss ich so langsam doch in ETH
umschichten  

ETH zusätzlich zu halten ist eine gute idee.
SegWit wird aber aktiviert. SegWit2x ist ebenfalls "normales" SegWit und wird schon bei 80% aktiv. SegWit2x möchte in 6 Monaten zwar noch die Blockgröße auf 2mb vergrößern, aber da wird Core nicht mitmachen. Also wird zum Schluss die Blockgröße bei 1mb zusammen mit SegWit übrigbleiben. Ich spekuliere hier natürlich nur, kann mir aber nicht vorstellen, dass die Core-Entwickler in 6 Monaten zustimmen. Gibt ja kein Grund für die Blockvergrößerung und sie waren von anfang an dagegen.

[d5000]

Die AKtivierungsschwelle von 95% über ca 2 Wochen heißt ja etwas anderes. Wenn dies erreicht ist, ist SegWit Pflicht für alle zukünftigen Blöcke.

Der Witz an SegWit aber ist doch, dass sie schon nach den jetztigen Regeln gültig sind. Deswegen ist es ja auch nur ein Softfork. Und aus diesem Grund, sollte er eben doch von den anderen Minern akzeptiert werden.

So einfach ist das halt nicht - der Softfork-Mechanismus (BIP 9) sieht extra die Schwelle vor, damit die Blockchain weiter konsistent bleibt und z.B. kein Chain Split entsteht. Denn ein Softfork ist trotz allem ein Fork: Das Regelwerk ändert sich, Blöcke nach den alten Regeln werden dadurch für Clients, die nach den neuen Regeln arbeiten, gegebenenfalls ungültig (sobald sie auch nur eine Transaktion enthalten, die durch die neuen Regeln nicht mehr gültig ist).

Nehmen wir mal an, diese 95%-Schwelle bestehe nicht und ab einem bestimmten Block begännen einige Miner einfach so, Segwit-Blocks zu minen. Dann würden eine Zeitlang weiterhin Blocks von alten Clients gemint. In diesen Blöcken können aber die neuen Regeln nicht gelten. Deswegen würden sie von den Segwit-Minern ignoriert. Es entstünde Chaos, da ständig Blocks alter Miner georphaned würden.

Siehe dazu auch hier: https://en.bitcoin.it/wiki/Softfork

In order for a softfork to work, a majority of the mining power needs to be running a client recognizing the fork. The more miners that accept the new rules, the more secure the network is post-fork. If you have 3/4 of miners recognizing the fork, 1/4 blocks created aren't guaranteed to follow the new rules. These 1/4 blocks will be valid to old nodes that aren't aware of the new rules, but they will be ignored by new nodes. This allows a "fake confirmation" vulnerability, an attacker could create a transaction paying to their victim, but have it end up in a block not following new rules, they might bribe a miner to make the block incompatible with new rules or make the transaction itself incompatible. Because 3/4 the hashrate won't mine on top of the block, the block and the transaction paying to you will eventually not be in the "mainchain" allowing the attacker to attempt to doublespend.

Deshalb ist eine hohe Schwelle durchaus sinnvoll - ob 95% oder 80% macht nicht so viel aus, aber mehr als drei Viertel sollten schon die neuen Regeln akzeptieren können.

[minime]

abwarten am ende wird bitcoin von denen zerstört die davon profitieren lol

[shinjikun]

Vieln dank schon mal für die Antwort d5000.

Mir ist BIP 9, also der Softfork-Mechanismus klar und er ist natürlich auch richtig so.

So wie ich das verstehe, führt eine Regeländerung zu einem fork.

Werden die Regln gelockert handelt es sich um einen hardfork. Wenn ich also ab jetzt 2mb statt nur 1mb erlaube habe ich ja die Regeln gelockert, aber das würde alle zurückweisen, die noch nach den alten Regeln arbeiten. Es spielt also auch keine Rolle wiviele Miner mit nochsoviel Hash-Power darauf arbeiten und wie lang diese Kette wird. Für die Nodes nach den alten Regeln würde diese Kette schlicht nicht existieren.

Eine Regelverschärfung führt dagegen zu einen softfork. Nehmen wir sinnloserweise an, die Regelverschärfung würde bedeuteen ab jetzt nur noch 0,5mb Blöcke zuzulassen. Hier müssten die Nodes nach den alten Regeln nicht zwangsweise aktualisiert werden, denn auch die 0,5mb Blöcke sind nach den alten Regeln voll gültig. Es ist an der Stelle nur wichtig, dass die Miner mitspielen und zwar am besten mit min. 80%.
Damit die Kette mit den neuen Regeln auch garantiert die längste und damit gültige ist.

Aber das gilt ja nur für den fork an sich. Also dass alle Blöcke nach den neuen Regeln spielen.
Einen Regelverschärfenden Block kann ich doch jederzeit generieren, da er trotzdem nach den alten Regeln spielt. In diesen Beispiel könnte ich als miner also jederzeit nur 0,5mb Blöcke generieren. Es macht zwar keinen Sinn, aber darum geht es mir nicht. Mir geht es darum, dass SegWit eine Blockoptimierung zu den jetzigen Regel ist die erst zum fork wird, wenn miner beginnen Blöcke die nicht optimiert werden als ungültig abzulehen.
Und wieder: Mir ist klar, dass das notwendig sein wird um zum Beispiel lightning zu ermöglich.
Aber nehmen wir an ich wäre einer Miner. Ich würde doch eigentlich jetzt sofort die optimierte Variante nehmen um mein Block zusammen zu bauen. Da passen ja mehr Transaktionen rein und ich erhalte mehr Gebühren. Ob der nächste Miner dann wieder nach den alten Regeln arbeitet, kann mir als egoistischen Miner doch egal sein.
 

[minime]

Vieln dank schon mal für die Antwort d5000.

Mir ist BIP 9, also der Softfork-Mechanismus klar und er ist natürlich auch richtig so.

So wie ich das verstehe, führt eine Regeländerung zu einem fork.

Werden die Regln gelockert handelt es sich um einen hardfork. Wenn ich also ab jetzt 2mb statt nur 1mb erlaube habe ich ja die Regeln gelockert, aber das würde alle zurückweisen, die noch nach den alten Regeln arbeiten. Es spielt also auch keine Rolle wiviele Miner mit nochsoviel Hash-Power darauf arbeiten und wie lang diese Kette wird. Für die Nodes nach den alten Regeln würde diese Kette schlicht nicht existieren.

Eine Regelverschärfung führt dagegen zu einen softfork. Nehmen wir sinnloserweise an, die Regelverschärfung würde bedeuteen ab jetzt nur noch 0,5mb Blöcke zuzulassen. Hier müssten die Nodes nach den alten Regeln nicht zwangsweise aktualisiert werden, denn auch die 0,5mb Blöcke sind nach den alten Regeln voll gültig. Es ist an der Stelle nur wichtig, dass die Miner mitspielen und zwar am besten mit min. 80%.
Damit die Kette mit den neuen Regeln auch garantiert die längste und damit gültige ist.

Aber das gilt ja nur für den fork an sich. Also dass alle Blöcke nach den neuen Regeln spielen.
Einen Regelverschärfenden Block kann ich doch jederzeit generieren, da er trotzdem nach den alten Regeln spielt. In diesen Beispiel könnte ich als miner also jederzeit nur 0,5mb Blöcke generieren. Es macht zwar keinen Sinn, aber darum geht es mir nicht. Mir geht es darum, dass SegWit eine Blockoptimierung zu den jetzigen Regel ist die erst zum fork wird, wenn miner beginnen Blöcke die nicht optimiert werden als ungültig abzulehen.
Und wieder: Mir ist klar, dass das notwendig sein wird um zum Beispiel lightning zu ermöglich.
Aber nehmen wir an ich wäre einer Miner. Ich würde doch eigentlich jetzt sofort die optimierte Variante nehmen um mein Block zusammen zu bauen. Da passen ja mehr Transaktionen rein und ich erhalte mehr Gebühren. Ob der nächste Miner dann wieder nach den alten Regeln arbeitet, kann mir als egoistischen Miner doch egal sein.
 

bau du ma weiter deine blöcke zu sammen lol

[shinjikun]

Nö, Blöcke sind sowieso von gestern. DAGs sind wahrscheinlich die Zukunft 

[minime]

das seh ich anders, wo ist der anreiz eth auszugeben wenn nur neue eth bekommst wenn du schon welche in der geldbörse hast??
das wöre ja so ups ich habe da ja noch 150dollar in der geld börse die lass ich da sind ja bald 151,5 und dann 154 etc...

[minime]

beschäftige dich am besten mal ein wenig mit dem thema du bist grad ma nen halbes jahr hier registriert.
es werden keine regeln geändert es wird der code geändert...
die leute spielen dabei mit oder nicht... man hätte die änderungen einfach durch setzten sollen wofür gibts das coredev team... gavin...

[shinjikun]

Ich nehme mal an du sprichst von Byteball.
Was du ansprichst hat aber nichts mit der Technik hinter der DAG als solche zu tun, sondern mit der Art der Distribution.
Aber ist schon schön die Technik abzulehen, weil man ja was geschenk kriegt.
Wie dem auch sei. Das verschenken von Byteball endet in ca. 6 Monaten. Dann gibt es weniger Anreiz sie zu behalten.

[minime]

Ich nehme mal an du sprichst von Byteball.
Was du ansprichst hat aber nichts mit der Technik hinter der DAG als solche zu tun, sondern mit der Art der Distribution.
Aber ist schon schön die Technik abzulehen, weil man ja was geschenk kriegt.
Wie dem auch sei. Das verschenken von Byteball endet in ca. 6 Monaten. Dann gibt es weniger Anreiz sie zu behalten.

Ethash is the PoW system. It requires a ~1GB dataset known as the DAG (see Dagger Hashimoto). This typically takes hours to generate so we tend to memorise it. Clients wishing to store the DAG in a cache should conform to this spec in order to share the cache with other clients:

ich rede von pos den eth wechselt von pow auf pos

[shinjikun]

beschäftige dich am besten mal ein wenig mit dem thema du bist grad ma nen halbes jahr hier registriert.
es werden keine regeln geändert es wird der code geändert...
die leute spielen dabei mit oder nicht... man hätte die änderungen einfach durch setzten sollen wofür gibts das coredev team... gavin...

*Hust* Ich bin seit 2011 dabei. Nur nicht hier registriert.
Und ich weiß wovon ich rede. Aber der Dunning-Kruger-Effekt ist immer sehr wizig.

Ich nehme mal an du sprichst von Byteball.
Was du ansprichst hat aber nichts mit der Technik hinter der DAG als solche zu tun, sondern mit der Art der Distribution.
Aber ist schon schön die Technik abzulehen, weil man ja was geschenk kriegt.
Wie dem auch sei. Das verschenken von Byteball endet in ca. 6 Monaten. Dann gibt es weniger Anreiz sie zu behalten.

Ethash is the PoW system. It requires a ~1GB dataset known as the DAG (see Dagger Hashimoto). This typically takes hours to generate so we tend to memorise it. Clients wishing to store the DAG in a cache should conform to this spec in order to share the cache with other clients:

ich rede von pos den eth wechselt von pow auf pos

Ich nicht. Ich rede von "directed acyclic graph" Also die Technik hinter Byteball und Iota. Aber ok. Hätte ich ausschreiben sollen

[minime]

?

[minime]

das ist was ganz anderes

[minime]

aber auch hier denke ich nicht das dieses zukunft haben wird vielleciht als vertrags platform oder ähnlichem aber nicht als geld ersatz

[shorena]

Vieln dank schon mal für die Antwort d5000.

Mir ist BIP 9, also der Softfork-Mechanismus klar und er ist natürlich auch richtig so.

So wie ich das verstehe, führt eine Regeländerung zu einem fork.

Werden die Regln gelockert handelt es sich um einen hardfork. Wenn ich also ab jetzt 2mb statt nur 1mb erlaube habe ich ja die Regeln gelockert, aber das würde alle zurückweisen, die noch nach den alten Regeln arbeiten. Es spielt also auch keine Rolle wiviele Miner mit nochsoviel Hash-Power darauf arbeiten und wie lang diese Kette wird. Für die Nodes nach den alten Regeln würde diese Kette schlicht nicht existieren.

Das ist mir ein bisschen zu binär. Eine abwärtskompatible Änderung der Regeln ist ein Soft-Fork eine Änderung die mit existierenden Implementationen bricht ein Hard-Fork. Bei einem Soft-Fork muss ich nicht gleich einsteigen und habe erstmal keine/kaum Nachteile. Im Falle von SegWit ist mein Nachteil das ich kein Full Node mehr habe, wenn ich die neuen Regeln nicht verstehe. Bei einem Hard-Fork muss ich mitmachen ober bin raus. Es entstehen zwei neue Coins mit einer gemeinsamen Historie. Beide können überleben.

Eine Regelverschärfung führt dagegen zu einen softfork. Nehmen wir sinnloserweise an, die Regelverschärfung würde bedeuteen ab jetzt nur noch 0,5mb Blöcke zuzulassen. Hier müssten die Nodes nach den alten Regeln nicht zwangsweise aktualisiert werden, denn auch die 0,5mb Blöcke sind nach den alten Regeln voll gültig. Es ist an der Stelle nur wichtig, dass die Miner mitspielen und zwar am besten mit min. 80%.
Damit die Kette mit den neuen Regeln auch garantiert die längste und damit gültige ist.

Das ist ja aber bei SegWit gerade nicht gegeben. Wie minime schon sagte 80% oder 95% ist nicht so wichtig. 47% hingegen ist ein Problem.

Aber das gilt ja nur für den fork an sich. Also dass alle Blöcke nach den neuen Regeln spielen.
Einen Regelverschärfenden Block kann ich doch jederzeit generieren, da er trotzdem nach den alten Regeln spielt. In diesen Beispiel könnte ich als miner also jederzeit nur 0,5mb Blöcke generieren.

Als Miner hast du dadurch nur einen ökonomischen Nachteil, weil du auf Gebühren verzichtest. Bei SegWit geht es aber um eine neue Art von Transaktion. Für einen Node der nicht mitmacht sieht das Script aus wie "anyone-can-pay", es gibt solche Transaktionen auch schon und sie wurden auch bestätigt. Du kannst sie aber nicht ausgeben bis SegWit TX nicht als gültige Eingänge akzeptiert werden. Ich bin mir hier gerade nicht zu 100% sicher ob das wirklich so ist oder ob es dir dann nur keinen Vorteil bringt weil du das RedeemScript wieder in dem üblichen 1MB Limit unterbringen musst. Im Endergebnis macht es aber kaum einen Unterschied. Entweder hast du dein Geld verbrannt was niemand riskieren würde oder du kannst die Vorteile nicht nutzen. CMIIW(!)

Es macht zwar keinen Sinn, aber darum geht es mir nicht. Mir geht es darum, dass SegWit eine Blockoptimierung zu den jetzigen Regel ist die erst zum fork wird, wenn miner beginnen Blöcke die nicht optimiert werden als ungültig abzulehen.
Und wieder: Mir ist klar, dass das notwendig sein wird um zum Beispiel lightning zu ermöglich.

Lightning geht auch ohne SegWit, es ist nur einfacher mit weil SegWit die malleability der TX-IDs behebt.

Aber nehmen wir an ich wäre einer Miner. Ich würde doch eigentlich jetzt sofort die optimierte Variante nehmen um mein Block zusammen zu bauen. Da passen ja mehr Transaktionen rein und ich erhalte mehr Gebühren. Ob der nächste Miner dann wieder nach den alten Regeln arbeitet, kann mir als egoistischen Miner doch egal sein.

SegWit ist halt nicht einfach nur eine Optimierung, sondern eine neue Art RedeemScript. Damit dein Block als gültig akzeptiert wird müssen alle TX die Teil davon sind gültig sein. Das ist für "zu"-SegWit Script TX kein Problem und ich bin mir sicher das auch schon gesehen zu haben (P2PKH nested in P2SH?), aber wenn dieser Eingang nun verwendeten werden soll muss wieder das vollständige Script in den Block.

-snip-
du bist grad ma nen halbes jahr hier registriert.
-snip-

weia, ich persönlich finde son tripple post ja deutlich peinlicher als n frischen Account zu haben.

[d5000]

Einen Regelverschärfenden Block kann ich doch jederzeit generieren, da er trotzdem nach den alten Regeln spielt. In diesen Beispiel könnte ich als miner also jederzeit nur 0,5mb Blöcke generieren. Es macht zwar keinen Sinn, aber darum geht es mir nicht. Mir geht es darum, dass SegWit eine Blockoptimierung zu den jetzigen Regel ist die erst zum fork wird, wenn miner beginnen Blöcke die nicht optimiert werden als ungültig abzulehen.

Du brauchst eben auch Nutzer, die die neuen Regeln überhaupt nutzen. Also im Fall Segwit die Segwit-Transaktionen. Ohne die kann ein Miner meines Wissens nach keine (von den alten Blöcken unterschiedliche) Segwit-Blöcke minen.

Nutzer werden aber die Segwit-Transaktionen erst nutzen, wenn diese die gleiche Sicherheit bieten wie die alten Transaktionen. Da aber alte Miner Segwit-Transaktionen gar nicht verstehen und validieren können, ist eine "Confirmation" von einem alten Miner nichts wert.

Insofern wird niemand Segwit-TX nutzen, da sie sich so einem Sicherheitsrisiko aussetzen würden - und dann kann der Miner, der schon jetzt "Segwit-Blöcke" minen möchte, dadurch auch keinen Vorteil durch Fees erreichen. Denn gerade die größere Kapazität kommt nur dann zustande wenn eben viele Segwit nutzen.

Ich muss aber zugeben dass die Sache tatsächlich ziemlich knifflig ist. Im Endeffekt kommt es darauf raus, dass die Miner eben doch keinen Anreiz haben, "vorzupreschen" - und sie sich daher lieber an die Update-Regeln von BIP9 halten. Du hast aber inzwischen ja sowieso im englischen Forum nach "allashrafs" geschrieben, das Thema verstanden zu haben - also gehe ich davon aus, dass das Thema erledigt ist.