Topic: Warum ist SegWit nicht jetzt schon aktiviert (Read 1370 times)
Ich persönlich denke, dass bis zum letzten gezogen wird, und stimmt dann. Die Chinesen sind zur Zeit erhitzt Tasche. Vor dem 1. August erwarte ich ein weiteres Rennen bis 2500, und dann einem starken Rückgang. Und wieder die Creme der Chinesen werden entfernt.
Aktuell verdoppelt Segwit die Blocksize. Mehr aber nicht. Das wird auf lange Sicht (je nach Adaption) nicht reichen.
-snip-
ich hätte meinen post auch editiern können... tss is mir aber auch recht latte was du als peinlich empfindest oder nicht ich das geht mir ehrlich am allerwertesten vorbei...
ich hätte meinen post auch editiern können... tss is mir aber auch recht latte was du als peinlich empfindest oder nicht ich das geht mir ehrlich am allerwertesten vorbei...
offensichtlich
ich empfinde nicht nur eure diskussion als schwachsinnig und peinlich... das nichts anderes als sich in irgendeiner weise wichtig zu machen anstatt das man sich selber alles durch ließt will man am besten noch das einem der löfel beim essen zum mund geführt wird.. und dannoch den btc mit irgendsom pyramiden schema zu vergleich... tsss
just my 2 btc
just my 2 btc
Ganz schön teuer
Es gibt unterschiedliche Arten zu lernen und Dinge zu verstehen, wenn lesen für dich ausreicht ist das Super. Das gilt aber nicht für alle. Für andere ist ein Dialog vielleicht wichtig, der ihnen Denkfehler aufzeigt. Solange man dabei offen bleibt sehe ich daran nichts verwerfliches. 'Geh dich mal informieren' hilft niemandem weiter. Wenn du mehr weißt, dann erklär es doch. Wenn du es nicht kannst, hast du es vielleicht selber nicht gut genug verstanden. https://www.amazon.de/Bitcoin-Banking-Banking-Bitcoin-Charlie-Shrem/dp/B06XF1Y796/ref=sr_1_1?s=instant-video&ie=UTF8&qid=1498801442&sr=1-1&keywords=bitcoin
ich habe ein problem damit wenn man merkt das sich nicht wirklich mit dem thema beschäftigt wurde und das kann man anhand der fragen erkennen.
-snip-
ich hätte meinen post auch editiern können... tss is mir aber auch recht latte was du als peinlich empfindest oder nicht ich das geht mir ehrlich am allerwertesten vorbei...
ich hätte meinen post auch editiern können... tss is mir aber auch recht latte was du als peinlich empfindest oder nicht ich das geht mir ehrlich am allerwertesten vorbei...
offensichtlich
ich empfinde nicht nur eure diskussion als schwachsinnig und peinlich... das nichts anderes als sich in irgendeiner weise wichtig zu machen anstatt das man sich selber alles durch ließt will man am besten noch das einem der löfel beim essen zum mund geführt wird.. und dannoch den btc mit irgendsom pyramiden schema zu vergleich... tsss
just my 2 btc
just my 2 btc
Ganz schön teuer
Es gibt unterschiedliche Arten zu lernen und Dinge zu verstehen, wenn lesen für dich ausreicht ist das Super. Das gilt aber nicht für alle. Für andere ist ein Dialog vielleicht wichtig, der ihnen Denkfehler aufzeigt. Solange man dabei offen bleibt sehe ich daran nichts verwerfliches. 'Geh dich mal informieren' hilft niemandem weiter. Wenn du mehr weißt, dann erklär es doch. Wenn du es nicht kannst, hast du es vielleicht selber nicht gut genug verstanden. 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.
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.
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.
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.
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-
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.
ich empfinde nicht nur eure diskussion als schwachsinnig und peinlich... das nichts anderes als sich in irgendeiner weise wichtig zu machen anstatt das man sich selber alles durch ließt will man am besten noch das einem der löfel beim essen zum mund geführt wird.. und dannoch den btc mit irgendsom pyramiden schema zu vergleich... tsss
just my 2 btc
Ja. Naja. Sagen wir ich verstehe das Thema Bitcoin jetzt wieder ein wenig besser.
Irgendwie hatte ich einen Nagel im Kopf und dachte SegWit betrifft nur Blöcke. An die Transaktionen habe ich nicht gedacht.
Wirklich. Vielen Dank euch allen.
Irgendwie hatte ich einen Nagel im Kopf und dachte SegWit betrifft nur Blöcke. An die Transaktionen habe ich nicht gedacht.
Wirklich. Vielen Dank euch allen.
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.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.
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.
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.
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.
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-
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.
aber auch hier denke ich nicht das dieses zukunft haben wird vielleciht als vertrags platform oder ähnlichem aber nicht als geld ersatz
das ist was ganz anderes
?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...
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: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.
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
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: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.
ich rede von pos den eth wechselt von pow auf pos
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.
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.
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...
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...
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...
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...
Nö, Blöcke sind sowieso von gestern. DAGs sind wahrscheinlich die Zukunft
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.
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
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.
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.
abwarten am ende wird bitcoin von denen zerstört die davon profitieren lol
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.
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
Quote
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.
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
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.
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
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
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.
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.
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?
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/
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?
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?
Jump to: