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.
Das zeigt doch nur, wie stabil & robust das Netzwerk funktioniert und das sollte das Vertrauen in Bitcoin weiter steigern.
Somit wird auch der Kurs weiter anziehen...
Somit wird auch der Kurs weiter anziehen...
Nö, das zeigt eher wie schlampig der Software implementiert wird. Spätestens im 2. Semester lernt ein Informatikstudent das man beim testen systematisch vorgeht und gegen Grenzwerte testet. Und ein Testnetz mit ein paar Rechnerknoten bei denen ein Knoten dann mal auch einen Block mit 1MB generierst wäre doch wohl nun nicht zu viel verlangt.
Quote
Wäre sowas im Fiat-Bankensystem passiert, hätte es eine Weltwirtschaftskriese verursacht
Hätte der Bitcoin die Bedeutung des Fiat Bankensystems, hätte es auch eine Weltkrise gegeben.
Nur das das Fiat Bankensystem nicht nur 'eine' Software benutzt sondern eben eine Vielzahl von Versionen. Da kann so ein Fehler wohl eher nicht passieren.
Das ganze war seit 2010 der erste größere 'Glitch'.
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139
Der Fork wurde aber nur 6 Stunden alt bis er wieder assimiliert wurde, bzw. die Transaktionen in ihm.
Am Anfang dachte ich jetzt wirds spannend, was für ein Abenteuer.
Das es jetzt so schnell geklappt hat hätte ich nie gedacht.
Die Schnelligkeit der Lösung des Problems und der Konsens darüber hat mich heute wirklich überrascht.
Ich hoffe das man jetzt das Blocksize - Problem final löst !
https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139
Der Fork wurde aber nur 6 Stunden alt bis er wieder assimiliert wurde, bzw. die Transaktionen in ihm.
Am Anfang dachte ich jetzt wirds spannend, was für ein Abenteuer.
Das es jetzt so schnell geklappt hat hätte ich nie gedacht.
Code:
Can we have a bitcoin holiday every March 12th?
Fork Day.
No work. Have fun.
Relax man.
Fork Day.
No work. Have fun.
Relax man.
Die Schnelligkeit der Lösung des Problems und der Konsens darüber hat mich heute wirklich überrascht.
Ich hoffe das man jetzt das Blocksize - Problem final löst !
Positiv finde ich die schnelle Entdeckung und Reaktion auf den Fehler.
Negativ ist, dass jetzt über eine konzentrierte Aktion der Miner ein Fork zum Gewinner ernannt wurde, der nach dem Regelsatz eigentlich verloren hätte. Durch die Zentralisierung mit einem einzigen übermächtigen Client blieb vermutlich gar nichts anderes übrig um den Schaden zu begrenzen. Allerdings erinnert mich das ganz Fatal an die "alternativlose" Bankenrettung, wenn die festgelegten Regeln zur Abwehr eines grossen Übels ausser Kraft gesetzt werden können. Ich würde mir wünschen, dass Bitcoin eines Tages an einem Punkt ist, wo das nicht mehr notwendig, aber auch nicht mehr möglich ist.
Negativ ist, dass jetzt über eine konzentrierte Aktion der Miner ein Fork zum Gewinner ernannt wurde, der nach dem Regelsatz eigentlich verloren hätte. Durch die Zentralisierung mit einem einzigen übermächtigen Client blieb vermutlich gar nichts anderes übrig um den Schaden zu begrenzen. Allerdings erinnert mich das ganz Fatal an die "alternativlose" Bankenrettung, wenn die festgelegten Regeln zur Abwehr eines grossen Übels ausser Kraft gesetzt werden können. Ich würde mir wünschen, dass Bitcoin eines Tages an einem Punkt ist, wo das nicht mehr notwendig, aber auch nicht mehr möglich ist.
Das Netz ist wieder auf der korrekten Blockchain
received block 000000000000016924f85069603be8164578eedf113f44d60bf0438cba047c7f
REORGANIZE: Disconnect 25 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 0df96f272c3b1e9dd15272b55750966cbd239219b94756c73ec
REORGANIZE: Connect 26 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 16924f85069603be8164578eedf113f44d60bf0438cba047c7f
Committing 42019 changed transactions to coin database...
Die Datenbank, die in den alten Versionen <= 0.7 genutzt wird, aktzeptiert nur bis zu 1700 Transaktionen pro Block. Das Bitcoin Block Limit wird in Speicherplatz angegeben und ist 1MB gross. Bisher haben die Miner diese Grösse freiwillig(!) auf 250KB eingeschränkt, was bedeutet, dass letztendlich keine 1700 Transaktionen im Block landen und damit das Limit der Datenbank nicht erreicht wird. Trotzdem aktzeptiert jeder Knoten schon immer Blöcke bis 1MB. Nun hat der erste Miner angefangen, dieses vom Protokol erlaubte mögliche Limit tatsächlich zu nutzen -> BUMM!
Das habe ich anders verstanden. (mein Englisch ist nicht sehr gut)
Die 0.8 hat gar nichts verursacht, was nicht durch die Bitcoin Regeln vorgesehen war.
Die 0.7 hat einen Fehler beim Speichern der Transaktionen, sodass die mögliche Anzahl Transaktionen, die in einem bis zu 1MB grossen Block auftreten können nicht aktzeptiert wird. Das 1MB Limit gehört zu den Bitcoin Regeln und gegen die hat 0.7 und älter verstossen.
Die 0.7 hat einen Fehler beim Speichern der Transaktionen, sodass die mögliche Anzahl Transaktionen, die in einem bis zu 1MB grossen Block auftreten können nicht aktzeptiert wird. Das 1MB Limit gehört zu den Bitcoin Regeln und gegen die hat 0.7 und älter verstossen.
Ein Client sollte so programmiert sein, das er mit seiner Neuerung erst nach n-Blocks aktiv werden kann, so wäre eine große Verbreitung zu vermuten.
Mann musste von der 0.8er Version auf die 0.7er zurück gehen, weil das was die 0.8 verursacht hat nicht vorgesehen war.
Mann musste von der 0.8er Version auf die 0.7er zurück gehen, weil das was die 0.8 verursacht hat nicht vorgesehen war.
Lustig. Vielleicht kann ich meine restlichen paar tausend USD bei mtGox jetzt doch in BTC tauschen.
Meine 0.8 Nodes habe ich selbstverständlich weiter am laufen. Es dauert einige Tage, bis die Nodes auf 500-1000 Connections kommen. Die sind als reine Support-Nodes allerdings auch nicht vom Problem betroffen, ausser dass sie auch Blocks mit vielen Transaktionen aktzeptieren und speichern.
Ich bin mal gespannt, wie die notwendigen Änderungen nun einfliessen. Die Anzahl der Transaktionen pro Block kann wohl erst dann steigen, wenn ein Grossteil der Teilnehmer auf dem 0.8 Stand ist oder entpsrechende Patches in den alten Releases sind. Alle die dann nicht mitziehen werden auf einer alternative (und ohne Miner toten) Chain sitzen.
Ein weiterer Gedanke: Wir brauchen dringend alternative Implementierungen an allen Stellen. Strenggenommen ist der Rückfall auf ein altes Verhalten, welches nicht von den Regeln abgedeckt ist eine Schande. Technisch gesehen wäre es korrekt, wenn fehlerhafte Nodes auf eine eigene Chain gedrängt werden, die im Idealfall dann ausstirbt. Im vorliegenden Fall wäre dann nur ein kleiner Teil der Nutzer betroffen gewesen und die müssten nun patchen um nicht auf einem toten Ast zu sitzen. So ist es leider der falsche Ast gewesen, der nun zur Referenz erklärt wurde. Es ist kaum Schaden angerichtet worden, trotzdem sollte der Fall zu denken geben.
Meine 0.8 Nodes habe ich selbstverständlich weiter am laufen. Es dauert einige Tage, bis die Nodes auf 500-1000 Connections kommen. Die sind als reine Support-Nodes allerdings auch nicht vom Problem betroffen, ausser dass sie auch Blocks mit vielen Transaktionen aktzeptieren und speichern.
Ich bin mal gespannt, wie die notwendigen Änderungen nun einfliessen. Die Anzahl der Transaktionen pro Block kann wohl erst dann steigen, wenn ein Grossteil der Teilnehmer auf dem 0.8 Stand ist oder entpsrechende Patches in den alten Releases sind. Alle die dann nicht mitziehen werden auf einer alternative (und ohne Miner toten) Chain sitzen.
Ein weiterer Gedanke: Wir brauchen dringend alternative Implementierungen an allen Stellen. Strenggenommen ist der Rückfall auf ein altes Verhalten, welches nicht von den Regeln abgedeckt ist eine Schande. Technisch gesehen wäre es korrekt, wenn fehlerhafte Nodes auf eine eigene Chain gedrängt werden, die im Idealfall dann ausstirbt. Im vorliegenden Fall wäre dann nur ein kleiner Teil der Nutzer betroffen gewesen und die müssten nun patchen um nicht auf einem toten Ast zu sitzen. So ist es leider der falsche Ast gewesen, der nun zur Referenz erklärt wurde. Es ist kaum Schaden angerichtet worden, trotzdem sollte der Fall zu denken geben.
Eigentlich ist ja nur das passiert was schon lange diskutiert wurde. Das erzeugen von größeren Blöcken......
Hätten jetzt alle die 0.8er Version wäre nichts passiert. Bloß es darf nicht unvorhergesehen passieren.
Es war aber ein tolles Beispiel wie ein dezentrales System sich äußerst effektiv und schnell reguliert....
Wäre sowas im Fiat-Bankensystem passiert, hätte es eine Weltwirtschaftskriese verursacht...))
Das einzigste Negative war, dass es mitten in der Nacht geschah und ich nicht günstig kaufen konnte....
((
Hätten jetzt alle die 0.8er Version wäre nichts passiert. Bloß es darf nicht unvorhergesehen passieren.
Es war aber ein tolles Beispiel wie ein dezentrales System sich äußerst effektiv und schnell reguliert....
Wäre sowas im Fiat-Bankensystem passiert, hätte es eine Weltwirtschaftskriese verursacht...
)) Das einzigste Negative war, dass es mitten in der Nacht geschah und ich nicht günstig kaufen konnte....
((
07:37 Uhr
Sieht so aus als wäre die 0.7er jetzt wieder die längere Chain.
https://blockchain.info/blocks
Sieht so aus als wäre die 0.7er jetzt wieder die längere Chain.
https://blockchain.info/blocks
Eine sehr gute Chronologie der letzten Nacht:
http://www.thebitcointrader.com/2013/03/breaking-blockchain-has-forked.html
Sehr geil: Update 15. Ghostbusters Totale Neutronen Umkehr. -> kreuzt die Ströme/Chains ! LOL.
Meine Vermutung...
EDIT: Problem wurde nach kurzer Zeit behoben.
Für die Akten:
_______________________________________
http://bitcoin.org/chainfork.html
Ein 0.8er Miner hat einen grossen Block kreiert der mit 0.7 und darunter nicht mehr kompatibel war.
Es entstand ein Fork, eine Abspaltung. Das heißt es gab/gibt 2 Blockchains.
Man hat sich auf die 0.7er Version verständigt da das das kleinste Risiko darstellt.
Die grossen Pools wurden gebeten auf 0.7 zu gehen, BTC Guild ist auf 0.7 gegangen.
https://bitcointalksearch.org/topic/m.1613480
weitere:
Bitminter 2000 GH/s
Bitparking 130 GH/s
Deepbit 4200 GH/s (on 0.6, so unaffected)
EMC 1900 GH/s
Eligius 400 GH/s (on 0.6, so unaffected)
Ozcoin 900 GH/s (on 0.6.3, so unaffected)
Slush's pool 3600 GH/s (0.8 with sipa patch, so unaffected)
mtgox und andere Börsen haben Überweisungen gestoppt:
https://support.mtgox.com/entries/21477395-Bitcoin-blockchain-issue-bitcoin-deposits-temporarily-suspended
weitere Threads überall im Forum
https://bitcointalksearch.org/topic/alert-chain-fork-caused-by-pre-08-clients-dealing-badly-with-large-blocks-152030
und auf /r/Bitcoin/
Alle Überweisungen (außer sog. double spendings) die in der 0.8er Version stecken werden automatisch in der 0.7er aufgehen sobald diese wieder die längste Chain ist (eine Zeit lang ist die 0.8er Chain die schneller wachsende gewesen).
Für die Akten:
_______________________________________
http://bitcoin.org/chainfork.html
Ein 0.8er Miner hat einen grossen Block kreiert der mit 0.7 und darunter nicht mehr kompatibel war.
Es entstand ein Fork, eine Abspaltung. Das heißt es gab/gibt 2 Blockchains.
Man hat sich auf die 0.7er Version verständigt da das das kleinste Risiko darstellt.
Die grossen Pools wurden gebeten auf 0.7 zu gehen, BTC Guild ist auf 0.7 gegangen.
https://bitcointalksearch.org/topic/m.1613480
weitere:
Bitminter 2000 GH/s
Bitparking 130 GH/s
Deepbit 4200 GH/s (on 0.6, so unaffected)
EMC 1900 GH/s
Eligius 400 GH/s (on 0.6, so unaffected)
Ozcoin 900 GH/s (on 0.6.3, so unaffected)
Slush's pool 3600 GH/s (0.8 with sipa patch, so unaffected)
mtgox und andere Börsen haben Überweisungen gestoppt:
https://support.mtgox.com/entries/21477395-Bitcoin-blockchain-issue-bitcoin-deposits-temporarily-suspended
weitere Threads überall im Forum
https://bitcointalksearch.org/topic/alert-chain-fork-caused-by-pre-08-clients-dealing-badly-with-large-blocks-152030
und auf /r/Bitcoin/
Alle Überweisungen (außer sog. double spendings) die in der 0.8er Version stecken werden automatisch in der 0.7er aufgehen sobald diese wieder die längste Chain ist (eine Zeit lang ist die 0.8er Chain die schneller wachsende gewesen).
Jump to: