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
Jump to: