Solved: 0.7 / 0.8 Fork

[klaus]

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://bitcointalk.org/index.php?topic=152048.msg1613480#msg1613480

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://bitcointalk.org/index.php?topic=152030.0

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).


 

[1714502964]

1714502964

[1714502964]

1714502964

[1714502964]

1714502964

[1714502964]

1714502964

[chmod755]

*YOUR

[joecooin]

[BTC-Fawkes]

Meine Vermutung...

[klaus]

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.

[klaus]

07:37 Uhr

Sieht so aus als wäre die 0.7er jetzt wieder die längere Chain.

https://blockchain.info/blocks

[xtral]

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....((

[mezzomix]

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.

[xtral]

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.

[mezzomix]

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.

[xtral]

Das habe ich anders verstanden. (mein Englisch ist nicht sehr gut)

[mezzomix]

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!

[klaus]

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...

[mezzomix]

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.

[klaus]

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.

Code:

Can we have a bitcoin holiday every March 12th?
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 !

[lame.duck]

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...

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.

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.

[Guajiro]

 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.

[klaus]

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.

[klaus]

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. 

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.

[mezzomix]

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.