Post fork plan:
Upgrade your bitcoind client to 0.8.1 by 15th of May.
Update Deinen bitcoind Client auf 0.8.1 bis zum 15. Mai 2013.
http://mineforeman.com/2013/03/17/post-fork-plan-upgrade-your-bitcoind-client-to-0-8-1-by-15th-of-may/
Gavin:
https://github.com/bitcoin/bitcoin/pull/2373
Gavin:
'Unpatched/outdated nodes will have an alert telling them they must upgrade.
And if they ignore the alert, when a too-large block is eventually created, they will be left behind. And their code will tell them... that they need to upgrade (the software notices when there is a longer fork that it can't validate).
And if they REALLY REALLY REALLY don't want to upgrade...there is a workaround that we'll describe.
In other words: Don't Panic.'
http://www.reddit.com/r/Bitcoin/comments/1afjld/fixes_for_081_release_by_gavinandresen_pull/c8wzv1n
Topic: Solved: 0.7 / 0.8 Fork (Read 2784 times)
@mezzomix: Das habe ich mir bei der ganzen Diskussion auch schon gefragt und daher im Bitcoin-Paper nachgelesen. Siehe bitcoin.org/bitcoin.pdf Dort ist kein Limit zu finden, ist aber allgemein eher oberflächlich gehalten und geht nicht in die technischen Details der Umsetzung.
redd
redd
@Mezzomix, was war unbekannt? Lies diesen Thread nochmal von vorne. Er wird alles erklärt. Die 0.7er Version ist "künstlich" kleingehalten was die mögliche Blockgröße anbelangt. Die 0.8er clients haben völlig korrekt und innerhalb des "Bitcoin-Reglements" agiert.
Gibt es irgendwo einen Link, wo man Nachvollziehen kann, dass das Lock Limit der BDB ein Teil des Bitcoin Regelsatz ist?!
Meiner Information nach hat das nichts mit der künstlichen Grössenbeschränkung zu tun, die man auch in 0.8 konfigurieren kann. Das BDB Limit ist eine harte Beschränkung, die man mit 0.7 und älter nicht durch eine Konfigurationsänderung beheben kann.
@Mezzomix, was war unbekannt? Lies diesen Thread nochmal von vorne. Er wird alles erklärt. Die 0.7er Version ist "künstlich" kleingehalten was die mögliche Blockgröße anbelangt. Die 0.8er clients haben völlig korrekt und innerhalb des "Bitcoin-Reglements" agiert.
Ich frag mich nur, wie man "kontrolliert" auf die 0.8er umschwenken will. Sollte man vielleicht schnell in die Wege leiten!? Den je mehr Leute beim "Bitcoinen" mitmachen, um so schwieriger wird es.
Ich frag mich nur, wie man "kontrolliert" auf die 0.8er umschwenken will. Sollte man vielleicht schnell in die Wege leiten!? Den je mehr Leute beim "Bitcoinen" mitmachen, um so schwieriger wird es.
Es bleibt nichts anderes übrige als zu hoffen, dass sich die 0.8er Version und Folgende nach und nach weit genug verbreiten. Vorher kann man im Prinzip nicht umstellen und die Umstellung wird so oder so weh tun, weil wir ja letztlich einen Hardfork brauchen, um über die 1MB-Grenze hinauszukommen. Andererseits: Wir haben jetzt so große Fortschritte gemacht, da werden wir das auch noch schaffen. Wenn nicht in diesem dann eben im nächsten Jahr. So ein Hardfork ist nun mal keine Kleinigkeit wie man es nun an dem unfreiwilligen Hardfork studieren konnte. Erst muss die Mehrheit der einfachen Clients updaten, erst dann können die Miner anfangen größere Blöcke zu schreiben. Ich denke, dass hat man aus dem Vorfall nun gelernt.
@Mezzomix, was war unbekannt? Lies diesen Thread nochmal von vorne. Er wird alles erklärt. Die 0.7er Version ist "künstlich" kleingehalten was die mögliche Blockgröße anbelangt. Die 0.8er clients haben völlig korrekt und innerhalb des "Bitcoin-Reglements" agiert.
Ich frag mich nur, wie man "kontrolliert" auf die 0.8er umschwenken will. Sollte man vielleicht schnell in die Wege leiten!? Den je mehr Leute beim "Bitcoinen" mitmachen, um so schwieriger wird es.
Grüße, Bernd
Ich frag mich nur, wie man "kontrolliert" auf die 0.8er umschwenken will. Sollte man vielleicht schnell in die Wege leiten!? Den je mehr Leute beim "Bitcoinen" mitmachen, um so schwieriger wird es.
Grüße, Bernd
0.7 und darunter konnten mit dem großen Block nicht arbeiten, ja in diesem Fall wegen technischer Restriktionen in der Berkeley DB.
Das Problem war in der 0.8er da damit keine Abwärtskompatibilität gewährleistet war.
Das ist klar. Aber ein unbekanntes Verhalten, dass die den bisher bekannten und aktzeptierten Regeln wiederspricht ist für mich ein Bug. Warum der drin ist, ist dann erst mal egal.
Ein Extrembeispiel wäre ein Bug, bei dem die Anzahl der Bitcoin pro Block ab einem gewissen Limit stark ansteigt und so die 21M Grenze sprengt und für Hyperinflation sorgt. Also ich wäre über so ein "Hidden Feature" alles andere als erfreut.
Coole graphische Darstellung des Fork und gute Zusammenfassung
http://mineforeman.com/2013/03/14/what-the-fork-was-that-a-forking-post-mortem/
Ein Bug ist für mich ein Fehler bei der Programmierung.
0.7 und darunter konnten mit dem großen Block nicht arbeiten, ja in diesem Fall wegen technischer Restriktionen in der Berkeley DB.
Das Problem war in der 0.8er da damit keine Abwärtskompatibilität gewährleistet war.
Also zuwenig / nicht getestet (Testnet).
Einfach quick&dirty das SatoshiDice/Transaktionen Blockgrößen - Problem (fehlerfrei) in der 0.8er gelöst.
Nur unser liebes Monster hat jedoch gezeigt was es von quick&dirty hält. LOL. Es bildete einen Fork. (kein Bug->sondern Feature
)Digital gedacht (0011001101 usw) völlig Spock - logisch. (Nachher ist man immer klüger).
Dazu muessten 0.7er und abwärts grosse Blöcke akzeptieren können, nur das können sie nun mal nicht.
Ich meine gelesen zu haben das der 0.7er Client sehr wohl diese Blöcke akzeptiert, aber nicht speichern kann, da es dabei ein Problem mit der Datenbank gibt.
Es gab in diesem Sinn keinen Bug sondern ein Kompatibilitätsproblem von der 0.8er zu allen anderen aelteren Versionen.
In diesem Sinne gibt es überhaupt keine Bugs
Vielleicht verkünden ja demnächst die Finanzminister das es in dem Sinne keine Inflation gibt sondern das das Geld noch im Miningphase ist und die maximale Summe der Euro, Dollar noch nicht erreicht wurde.
Bitcoin ist jetzt nicht mehr unschuldig.
War aber scheinbar der einzige der die Lücke für sich ausnutzte.
Außerdem hat Okpay vorher von ihm 64.91410001 BTC genommen, daher will er die 211 BTC jetzt nicht zurückgeben.
Der Kollege hat die 211 BTC zurückgezahlt, und Okpay hat ihm seine 64 BTC geschickt.
Alle sind wieder happy und haben sich lieb.
https://bitcointalksearch.org/topic/a-successful-double-spend-us10000-against-okpay-this-morning-152348
Dazu muessten 0.7er und abwärts grosse Blöcke akzeptieren können, nur das können sie nun mal nicht.
Aus diesem Grund hat sich der Fork gebildet!
Es gab in diesem Sinn keinen Bug sondern ein Kompatibilitätsproblem von der 0.8er zu allen anderen aelteren Versionen.
Aus diesem Grund hat sich der Fork gebildet!
Es gab in diesem Sinn keinen Bug sondern ein Kompatibilitätsproblem von der 0.8er zu allen anderen aelteren Versionen.
... und nicht der Fehler zur Regel erklärt werden...
ja Bugs zum Feature zu erklären hat Tradition in der Computerwelt 
Für dieses mal ist es schon vorbei, aber generell muss eigentlich der fehlerhafte Client gepatcht werden und nicht der Fehler zur Regel erklärt werden. Die Regeln zu ändern könnte irgend wann mal böse nach hinten losgehen. Vermutlich war Gavin deshalb auch so lange gegen diesen Schritt.
Hmmm,
Wenn die meisten Händler noch Software auf 0.7 Basis haben, dann macht es wohl mehr Sinn erstmal bei dieser zu bleiben, denn Händler haben erstens mehr unter der Möglichkeit eines Doppelspending zu leiden und die Softwareanpassungen für Händler sind wahrscheinlich auch komplizierter als die für Miner.
Außerdem können die 0.8 Clients auch 0.7 Blöcke verarbeiten während es anders rum nicht geht, d.h. sich ein wenig mehr Zeit zu nehmen bis mehr Clients geupdatet haben kann sicher nicht schaden.
Andererseits kann ich auch verstehen wenn man die 0.8 Block-Chain gültig erklärt hätte, da ja eigentlich die 0.7 Clients ihre Arbeit verweigern müssten wenn sie eine längere Block-Chain sehen als die wo sie gerade akzeptieren.
Andererseits ein gezwungener Update ohne große Vorbereitung bei Händlern könnte auch viele Bugs nach sich ziehen und wer weiß, vielleicht findet sich ja beim 0.8. selber noch ein Bug, so lange ist der auch noch nicht in Verwendung.
Naja wie dem auch sei, für diesesmal ist es bestimmt nicht schlecht gewesen erstmal 0.7 kompatibel zu bleiben.
Und generell sollte man als Miner vielleicht eher konservativ bleiben und warten bis mehr Clients geupdatet haben...
Wenn die meisten Händler noch Software auf 0.7 Basis haben, dann macht es wohl mehr Sinn erstmal bei dieser zu bleiben, denn Händler haben erstens mehr unter der Möglichkeit eines Doppelspending zu leiden und die Softwareanpassungen für Händler sind wahrscheinlich auch komplizierter als die für Miner.
Außerdem können die 0.8 Clients auch 0.7 Blöcke verarbeiten während es anders rum nicht geht, d.h. sich ein wenig mehr Zeit zu nehmen bis mehr Clients geupdatet haben kann sicher nicht schaden.
Andererseits kann ich auch verstehen wenn man die 0.8 Block-Chain gültig erklärt hätte, da ja eigentlich die 0.7 Clients ihre Arbeit verweigern müssten wenn sie eine längere Block-Chain sehen als die wo sie gerade akzeptieren.
Andererseits ein gezwungener Update ohne große Vorbereitung bei Händlern könnte auch viele Bugs nach sich ziehen und wer weiß, vielleicht findet sich ja beim 0.8. selber noch ein Bug, so lange ist der auch noch nicht in Verwendung.
Naja wie dem auch sei, für diesesmal ist es bestimmt nicht schlecht gewesen erstmal 0.7 kompatibel zu bleiben.
Und generell sollte man als Miner vielleicht eher konservativ bleiben und warten bis mehr Clients geupdatet haben...
Ich finds auch gut, wie schnell die Devs reagiert haben! Kompliment! Nach dem was ich so darüber gelesen haben, wäre ich aber wohl auch eher für die 0.8er Gewesen... Naja.
Rollback? Welcher Rollback?
Du meinst sicher Downgrade.
Das war es was durchgeführt wurde.
Es wurde die Power unseres Netzes auf die 0.7 anstatt die 0.8 gelegt.
Als der 0.7er Strang dann wieder und länger und stärker war sind die Transaktionen aus dem 0.8er Strang im 0.7er aufgegangen.
Bemerkenswert: Gavin war für 0.8. ..... 'Going backwards is the wrong thing to do, in my opinion'
Meine Meinung. Der Rollback aufgrund eines unvorhergesehenen Datenbankverhaltens der BDB Versionen war nur möglich, da es ausser dem Satoshi-Client keine ernstzunehmende Alternative im Netz gibt. Wäre dieser Client nur einer von vielen wäre der Rollback nicht notwendig und auch nicht möglich gewesen.
WOW ... ein sehr guter Abriss der IRC Ereignisse der Nacht. Liest sich wie ein Krimi.
Bemerkenswert: Gavin war für 0.8. ..... 'Going backwards is the wrong thing to do, in my opinion'
Die anderen Entwickler und vor allem BTCGuild waren jedoch für 0.7 und so wurde es dann gemacht.
mtgox hat auch in Minutenfrist reagiert und Überweisungen eingefroren.
-->> Quelle
Die längste Zeit die vergangen ist, ist die während man auf das überholen der 0.8er Version durch die 0.7er Version wartete.
Quote
11:30pm problem starts to come to light with one user struggling with their version 0.7 bitcoin client.
00:00 The problem didn’t really come to light however until about midnight, when a couple of devs starting noticing something was up.
00:05 It took a mere 5 minutes for “Luke-Jr” to correctly identify the hardfork with the message “Luke-Jr: so??? Yay accidental hardfork? ”
00:08 Just three minutes after Luke-Jr first identified the issue, user “sipa” tracks the problem to a bug (as yet unidentified) in the version 0.7 software. Also within three minutes The MtGox Bitcoin Exchange confirmed it was on Version 0.7 “old” software.
At this point Luke-Jr raises a concern “my immediate concern is, which fork are the majority of miners on?” which is echoed for the next few hours.
00:11 The Mt.Gox exchange stops accepting bitcoin transactions (concerned they could be double spent)
00:20 a few people start to freak out, and messages such as “omg what is going on” and “oh fuck” begin to appear in the chat.
But – in the same minutes (less than 15 minutes since the hardfork was identified) Luke-Jr (aka “hero for the evening”) suggests what will eventually become the short term fix, saying to a fellow dev “sipa: seems to me the best short-term fix is to get miners off 0.8”
00:22 merely two minutes after this fix was suggested a discussion begins between the devs on whether or not they can reach a consensus on this.
This is when lead developed Gavin Andresen joins the conversation and is initially very resistant to the proposal.
00:31 while a consensus has not yet been reached, major mining pool BTC Guild begins to take action on rolling back their software to version 0.7
00:39 Gavin Andresen expresses strong resistance to the proposed solution “Going backwards is the wrong thing to do, in my opinion”
00:43 the bitcoin price on MtGox begins to suffer dropping $2 to $46/BTC
00:45 Despite Gavin Andresens initial protest, the devs eventually reach consensus when BTC Guild announces they have the balance of hashing power and all agree to request pools downgrade to version 0.7 as a matter of urgency.
00:46 A bitcoin gambling website which has been at the brunt of a lot of blame, Satoshi Dice, comes to the party and pauses all transaction processing, lightening the load on the network.
00:50 the bitparking mining pool begins downgrading their software to version 0.7
01:15 the Mt Red mining pool shuts down its services as a quick solution to reduce hashing power on the version 0.8 blockchain.
01:19 Major bitcoin payment processer BitPay intentially freezes transactions to reduce the impact of a potential (but unlikely) double spend attack
01:23 Although struggling through a number of issues surrounding moving large files between servers, BTC Guild mining pool finally downgrades the first of its servers.
02:36 the BTC Guild mining pool downgrade is completed across all of its servers.
03:00 A temporary bandaid patch for software version 0.8 is release which should allow it to rejoin the 0.7 blockchain and ditch the problematic 0.8 blockchain
06:21 Everyones hard work is reworded as the fix proposed at 00:20 dominates the blockchain and the version 0.8 blockchain merges once more with the version 0.7 blockchain
06:23 The Mt Gox exchange announced they would wait until a further 6 block confirmations came through to ensure there was a clear winning/leading chain. This wasn’t necessary, but a cautious safeguard.
Conclusion:
While I don’t doubt at some point another accidental hardfork event might take place (although this was the first in over 225,000 blocks and 4 years), If such an event were to take place I would sleep easy knowing the bitcoin developers and community have things in hand.
My only other takeaway from this situation is a slight loss of faith in the lead developer of bitcoin, Gavin Andresen, who in my mind could have acted quicker and more decisively, and could in theory have lessened the impact by a matter of hours.
My own view is that Luke-Jr was the star of the evening (although he assumed the problem was with 0.8 software, not with 0.7 software, which was an easy assumption to come to in the heat of the moment) – Sipa was also a stand out contributor of the evening, taking an equally strong role in the recovery and working extremely effectively with Luke-Jr. In my mind these two deserve the praise.
I do wonder if there is scope for the creation of a centralised (although voluntary) notification system for the key players and network at large to close ranks more quickly in any future event such as this one, but I also think this would need to be managed with a very level head. In my mind last nights even should have been an amber warning event, not a panic event, as the solution was clear, simple and quick.
One honest bitcoin user has reported he was able to double spend $10,000 worth of bitcoin, but I believe this is more down to the payment processors flaws than it is the network and bitcoin protocol.
00:00 The problem didn’t really come to light however until about midnight, when a couple of devs starting noticing something was up.
00:05 It took a mere 5 minutes for “Luke-Jr” to correctly identify the hardfork with the message “Luke-Jr: so??? Yay accidental hardfork? ”
00:08 Just three minutes after Luke-Jr first identified the issue, user “sipa” tracks the problem to a bug (as yet unidentified) in the version 0.7 software. Also within three minutes The MtGox Bitcoin Exchange confirmed it was on Version 0.7 “old” software.
At this point Luke-Jr raises a concern “my immediate concern is, which fork are the majority of miners on?” which is echoed for the next few hours.
00:11 The Mt.Gox exchange stops accepting bitcoin transactions (concerned they could be double spent)
00:20 a few people start to freak out, and messages such as “omg what is going on” and “oh fuck” begin to appear in the chat.
But – in the same minutes (less than 15 minutes since the hardfork was identified) Luke-Jr (aka “hero for the evening”) suggests what will eventually become the short term fix, saying to a fellow dev “sipa: seems to me the best short-term fix is to get miners off 0.8”
00:22 merely two minutes after this fix was suggested a discussion begins between the devs on whether or not they can reach a consensus on this.
This is when lead developed Gavin Andresen joins the conversation and is initially very resistant to the proposal.
00:31 while a consensus has not yet been reached, major mining pool BTC Guild begins to take action on rolling back their software to version 0.7
00:39 Gavin Andresen expresses strong resistance to the proposed solution “Going backwards is the wrong thing to do, in my opinion”
00:43 the bitcoin price on MtGox begins to suffer dropping $2 to $46/BTC
00:45 Despite Gavin Andresens initial protest, the devs eventually reach consensus when BTC Guild announces they have the balance of hashing power and all agree to request pools downgrade to version 0.7 as a matter of urgency.
00:46 A bitcoin gambling website which has been at the brunt of a lot of blame, Satoshi Dice, comes to the party and pauses all transaction processing, lightening the load on the network.
00:50 the bitparking mining pool begins downgrading their software to version 0.7
01:15 the Mt Red mining pool shuts down its services as a quick solution to reduce hashing power on the version 0.8 blockchain.
01:19 Major bitcoin payment processer BitPay intentially freezes transactions to reduce the impact of a potential (but unlikely) double spend attack
01:23 Although struggling through a number of issues surrounding moving large files between servers, BTC Guild mining pool finally downgrades the first of its servers.
02:36 the BTC Guild mining pool downgrade is completed across all of its servers.
03:00 A temporary bandaid patch for software version 0.8 is release which should allow it to rejoin the 0.7 blockchain and ditch the problematic 0.8 blockchain
06:21 Everyones hard work is reworded as the fix proposed at 00:20 dominates the blockchain and the version 0.8 blockchain merges once more with the version 0.7 blockchain
06:23 The Mt Gox exchange announced they would wait until a further 6 block confirmations came through to ensure there was a clear winning/leading chain. This wasn’t necessary, but a cautious safeguard.
Conclusion:
While I don’t doubt at some point another accidental hardfork event might take place (although this was the first in over 225,000 blocks and 4 years), If such an event were to take place I would sleep easy knowing the bitcoin developers and community have things in hand.
My only other takeaway from this situation is a slight loss of faith in the lead developer of bitcoin, Gavin Andresen, who in my mind could have acted quicker and more decisively, and could in theory have lessened the impact by a matter of hours.
My own view is that Luke-Jr was the star of the evening (although he assumed the problem was with 0.8 software, not with 0.7 software, which was an easy assumption to come to in the heat of the moment) – Sipa was also a stand out contributor of the evening, taking an equally strong role in the recovery and working extremely effectively with Luke-Jr. In my mind these two deserve the praise.
I do wonder if there is scope for the creation of a centralised (although voluntary) notification system for the key players and network at large to close ranks more quickly in any future event such as this one, but I also think this would need to be managed with a very level head. In my mind last nights even should have been an amber warning event, not a panic event, as the solution was clear, simple and quick.
One honest bitcoin user has reported he was able to double spend $10,000 worth of bitcoin, but I believe this is more down to the payment processors flaws than it is the network and bitcoin protocol.
Bitcoin ist jetzt nicht mehr unschuldig.
War aber scheinbar der einzige der die Lücke für sich ausnutzte.
Außerdem hat Okpay vorher von ihm 64.91410001 BTC genommen, daher will er die 211 BTC jetzt nicht zurückgeben.
Gavin Andresen@Twitter: Chain fork resolved after 7 hours / 28 blocks; I will file this incident under "scaling up is always painful."
Hoffentlich lernen alle daraus und wir gehen mit noch mehr Vertrauen in BTC weiter...
Danke an die Dev´s für die schnelle und besonnene Lösung.
Hoffentlich lernen alle daraus und wir gehen mit noch mehr Vertrauen in BTC weiter...
Danke an die Dev´s für die schnelle und besonnene Lösung.
Jump to: