Atlas warned about database change some time ago. Original discussion here https://bitcointalk.org/index.php?topic=119566.0;all
Pffft! Credit where credit is due...He nailed it by my quick read.
Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 21. (Read 155565 times)
March 11, 2013, 10:27:24 PM
Pffft! Credit where credit is due...He nailed it by my quick read.
March 11, 2013, 10:26:53 PM
+1 to Devs
March 11, 2013, 10:24:06 PM
So if I may say something... I learned about this glitch fairly early on and immediately hopped into the bitcoin-dev IRC room. The impression I got was one of many brilliant, professional, dedicated bitcoin developers working together to resolve the issue. I was immensely impressed with them.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
Quoted for posterity. Hats off to you gents!
March 11, 2013, 10:24:04 PM
So,
- if you are using 0.8 and mining - stop mining and wait till proper instruction comes from the core development team.
- if you are using 0.7 and mining - stop mining and wait till proper instruction comes from the core development team.
- if you are using 0.8 and mining - stop mining and wait till proper instruction comes from the core development team.
- if you are using 0.7 and mining - stop mining and wait till proper instruction comes from the core development team.
Wait, what? No, just keep mining if on 0.7. Also, this really only affects the pools, not most of the miners.
Tycho has been very resistent to any change.
I thought there was like a 4gb limit on the databases in 0.3.x?
March 11, 2013, 10:23:43 PM
So if I may say something... I learned about this glitch fairly early on and immediately hopped into the bitcoin-dev IRC room. The impression I got was one of many brilliant, professional, dedicated bitcoin developers working together to resolve the issue. I was immensely impressed with them.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
anyway that chat log can be shared? I know a lot of people would love to read it.
March 11, 2013, 10:23:14 PM
Gavin just tweeted this: https://twitter.com/gavinandresen/status/311315494214987778
And suggested we go here for more info: http://bitcoin.org/chainfork.html
And suggested we go here for more info: http://bitcoin.org/chainfork.html
March 11, 2013, 10:22:57 PM
Atlas warned about database change some time ago. Original discussion here https://bitcointalk.org/index.php?topic=119566.0;all
I remember that and I remember that I dismissed the warning. I stand by the dismissal. Watch this get corrected to see why.For example:
Back up to $45+ ALREADY?? Could this widespread bug, and it's fairly fast community-assisted response, maybe actually bolster confidence in bitcoins? Or am I getting ahead of myself?
March 11, 2013, 10:21:50 PM
why the hell is Deepbit only on 0.3.21
Tycho has been very resistent to any change.... and Luke on 0.6.0?
Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict.It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time.
Its awesome how fast you caught this issue because of your setup.
March 11, 2013, 10:21:08 PM
So if I may say something... I learned about this glitch fairly early on and immediately hopped into the bitcoin-dev IRC room. The impression I got was one of many brilliant, professional, dedicated bitcoin developers working together to resolve the issue. I was immensely impressed with them.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
Even people like Luke-Jr and myself, who seem to be mortal enemies, worked politely together and did what was needed to contain the situation and fix things. Most of the people in the room stayed respectfully quiet and let the important work occur.
To all the amazingly intelligent devs who make this crazy shit actually work, my hat is off to you (even you, Luke-Jr!). Eternally impressed with your work, coordination, and skill. And this all being done for the simple passion of Bitcoin. Quite inspiring, really.
March 11, 2013, 10:20:58 PM
why the hell is Deepbit only on 0.3.21
Tycho has been very resistent to any change.... and Luke on 0.6.0?
Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict.It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time.
0.3.21 is ancient considering. i think from now on we're going to have to make a much more public list of what version different pools are running so that individual miners can make a more informed decision on who to align with.
March 11, 2013, 10:20:47 PM
Back up to $45+ ALREADY?? Could this widespread bug, and it's fairly fast community-assisted response, maybe actually bolster confidence in bitcoins? Or am I getting ahead of myself?
March 11, 2013, 10:20:09 PM
why the hell is Deepbit only on 0.3.21
Tycho has been very resistent to any change.... and Luke on 0.6.0?
Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict.It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time.
I love this guy.
Luke -- perhaps this is a good strategy for miners to adopt. Perhaps someone should pay you (the Foundation?) to keep running like this to catch bugs quickly.
March 11, 2013, 10:19:16 PM
The sequence of blocks on blockchain.info currently reads 225449, 225450, 225451, 225441, 225452.
no
It looks like that odd block got purged and it now reads in order.
March 11, 2013, 10:19:11 PM
I don't know if there are unit tests for the reference client, but I would bet there are. Not one of them, obviously, tests for transactions as large as the one that forked the blockchain being rejected by old clients, but accepted by the new one. Someone want to add that? I would, but I haven't been able to get bitcoin to compile (not enough effort on my part - sorry!).
The problem, if I understand correctly, is that the 0.7 client rejected a good block because it didn't fit in the 0.7 database, and this caused it to ignore the block solution while the 0.8 client accepted it. To the programmers way back when this code was being written, the assumption was that if one good client rejects a block, then all the good clients will reject it. That assumption was wrong, so we have a fork. BUT...
Both clients will continue to use the "blockchain with the highest cumulative difficulty" as the real transaction record. This means that any transaction on the "other" chain will be re-broadcast until it's in whichever chain is "real" (which might switch back and forth when there are two notions of "real" - one for 0.7 and another for 0.
. But the 0.7 client will never see the 0.8 chain as real because it has a too-large block in it.
The problem, if I understand correctly, is that the 0.7 client rejected a good block because it didn't fit in the 0.7 database, and this caused it to ignore the block solution while the 0.8 client accepted it. To the programmers way back when this code was being written, the assumption was that if one good client rejects a block, then all the good clients will reject it. That assumption was wrong, so we have a fork. BUT...
Both clients will continue to use the "blockchain with the highest cumulative difficulty" as the real transaction record. This means that any transaction on the "other" chain will be re-broadcast until it's in whichever chain is "real" (which might switch back and forth when there are two notions of "real" - one for 0.7 and another for 0.
. But the 0.7 client will never see the 0.8 chain as real because it has a too-large block in it. 
March 11, 2013, 10:17:00 PM
Atlas warned about database change some time ago. Original discussion here https://bitcointalk.org/index.php?topic=119566.0;all
March 11, 2013, 10:16:50 PM
why the hell is Deepbit only on 0.3.21
Tycho has been very resistent to any change.... and Luke on 0.6.0?
Eligius is actually running both 0.6.0 and 0.8.0 concurrently, but has 0.6.0 prioritized so it trumps 0.8.0 when there's a conflict.It noticed and began reporting the problem immediately, but I guess wizkid057 was busy with something at the time.
March 11, 2013, 10:15:20 PM
The sequence of blocks on blockchain.info currently reads 225449, 225450, 225451, 225441, 225452.
no
March 11, 2013, 10:15:00 PM
So has a majority hashrate-share of the mining pools finished downgrading yet? I.e., are we definitely now on the path to adopting the 0.7 blockchain?
March 11, 2013, 10:13:34 PM
This is being dealt with right now. Tomorrow it will be yet another example of the capability of an OS/P2P network to deal with and solve problems. We will walk out of this being stronger than before and we will have another story to tell our grandkids about the exciting times back then when Bitcoin became big. Priceless 
.
See it as a stress-test that no bank would survive.
If you don't see it like that and want to get rid of your coins at a low price please feel free to pm me and make me an offer, I will be online another 15 minutes before I go to bed and have a deep sleep even as an 'all-in-person'
.
Joe
.See it as a stress-test that no bank would survive.
If you don't see it like that and want to get rid of your coins at a low price please feel free to pm me and make me an offer, I will be online another 15 minutes before I go to bed and have a deep sleep even as an 'all-in-person'
.Joe
March 11, 2013, 10:13:11 PM
why the hell is Deepbit only on 0.3.21 and Luke on 0.6.0?
Jump to: