Pages:
Author

Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 18. (Read 155551 times)

legendary
Activity: 1002
Merit: 1000
Bitcoin
The original post lacked info for "regular users".  Here it is:

(1) If you are a "regular user" (not a miner), the best thing is to do nothing and wait a couple hours.
(2) If you are a "regular user",  Upgrading, downgrading, whining, FUD, etc, will make no difference.  Only miners have an incentive to do anything.
(3) Regardless of who you are, your transactions are not dead, your coins are not lost.  They will just temporarily be held up.  If you sent a transaction within the last few hours, it may take a few more hours before it's sorted out.
(4) If you insist on processing transactions right now it's probably best to wait 30+ confirmations.  It's just due diligence though ... an attacker would still need a tremendous amount of mining power, quick thinking, and a victim willing to part with a lot of BTC.
(5) By tomorrow this will be in the past and everything will appear to be normal again.  If you slept through this, you'd never know that anything happend (except for the price drop).

Let me reiterate, your coins are not at risk, your transactions are not lost.  It'll just take some time for the network to "iron itself out."  Everything will be okay.

Very good info.

+1

This is it..

Nice post !
hero member
Activity: 509
Merit: 564
"In Us We Trust"
Quote from: evoorhees date=00:59
Okay SatoshiDice is on pause now. Receiving bets but not processing anything.

Quote from: randy-waterhouse date=1:02
so now we can stop SatoshiDICE ... how convenient

See look guys, all it took was a hard fork  Cheesy

Easy!
legendary
Activity: 1904
Merit: 1037
Trusted Bitcoiner
is it almost over fully fixed?
legendary
Activity: 1400
Merit: 1013
But what I actually meant is that it is a bit surprising that the BerkeleyDB backed versions where not tested to a maximum block size (which, as I understand it, is expressed as a #DEFINE, and which, again in my understanding, was not changed between 0.7 and 0.8.)
Maybe they were tested, but the bug only appears in certain versions of BDB. Since a lot of people compile their own node software who knows how many versions of BDB operating nodes are linked against?

We probably won't know for sure until they have time to do a full postmortem.
legendary
Activity: 1512
Merit: 1036
Block progress - bad chain height = 225453; good chain = 225445, another hour + to go before the BIG REORG!

Soon to be orphaned:
Code:
000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023*225430
00000000000002d2012cc1b3fc0cceb8c156f0e698db40bf4413a210eca056c3*225431
00000000000002c9e42c23f6eed2b9f9152a440610dcfaf992357c3cbff3689c*225432
00000000000001b3c862fd66689712bc1cdd44fc004c008ada6c1b51367686f2*225433
00000000000002528688a366a9f42c07089268cd8a474961c49f787cb385807e*225434
00000000000000947452b814ed008f750023e64c8fd03bb19b3865716eeb243d*225435
00000000000001a23b3f38106f210493795a1ef6b21dd559f87ada8dfc84181b*225436
000000000000000016b3a292d63f9eea6b8177b8ba8dfd621d36fd828e5cb187*225437
000000000000019881625f04eac2046512fa1e1bd7193f56f39595d802bbbd04*225438
000000000000015aab28064a4c521d6a5325ff6e251e8ca2edfdfe6cb5bf832c*225439
00000000000003264ac7a6a74ca779997ee637b30f84debcb6ba6c26e2d09f4b*225440
0000000000000372a4c37e27587255ca77a6377391c1974f13ea55ec1d3bc01b*225441
0000000000000229cd059490b7607ca4c191c52bb40405fa052c48d72bfda8b0*225442
0000000000000213874009d269b90be16ea5c1f6a83a79ae2be3813d8972a2a3*225443
00000000000003381ed79de2fa810c0e4f0e9c0cd5d307380b779e2b5ffa982e*225444
00000000000000ec0df675972dddf0c2bdb1d436064672a6f0b79ce65ffcade6*225445
00000000000000757de9173ee2f01c9f957c8aa3b4f71b901b0fa19683ab1fa1*225446
00000000000000ec24f812807f81aadb7a665ef4ab8b8aa49df5ef789cdc13ff*225447
00000000000001f9fd0b0cab82deca5f53030911b33ba7dd7ce3fd77ad2c5a55*225448
00000000000001f15726ea57dc7702407a3ebc097ed801cb3d7b0e8a450807cb*225449
000000000000026a105de544bfbe71bca0820ac3963ba132c75ec40411b5f162*225450
00000000000003bdcc4424dea94de83e9f54ca158ae3eac59c2e97c2f90a32ad*225451
0000000000000190f5944e56c52600e9d8d4d5416432e03b324bc85c51629bcd*225452
000000000000031803e492a0103154d243c9945ef78dbdba42a1ecfdb5bc5dbb*225453

New 0.7-created blocks
Code:
00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932 225430
00000000000000f2c09bd58b84a7ef33fbc038a6fed97c072643b1e61d8ab841 225431
00000000000000362b16136f026a99ed5c59c0a4dc99e60fe87c28f3220438d6 225432
0000000000000040fcdf075576b52f2f83d852e4f356936645bcb4e745c94e15 225433
0000000000000105d2e2b2d0501ad1826bbd622c044fb77c865f98fce4781106 225434
000000000000027373b3fa7b123ca461e5c5d090c9caeb24a8bbbd32e1eaaa5d 225435
000000000000016e4bbe5cac005375b3dd799839c4b430959158b645b2dbafae 225436
000000000000022500c140cbc4ba13eebeb9859b08461c7a35fb233202ec8374 225437
0000000000000307714abe653fc80e966eca3bfe94e74697b5ec611b3c23ab96 225438
00000000000002b63d8aa07404d752703d12bf8b58a7663de30c71c719f9b2ce 225439
0000000000000025fcc0c001b11e542ae73dc4d9edc9ed9d82627563a2af5d81 225440
0000000000000133ecdb94ba8017e2977aefe3e497c48c849e3f9c4c7a091564 225441
000000000000003d3e6473a13a33ed9419bf3863d08c62e2a67abae871e2fac9 225442
00000000000001a2a869f12fab167b3506407cb62f16ff8e316a1d7b7cbd9d56 225443
000000000000007b7879107d003317325df8b3772a73f7a1c179ed99cb9d04b2 225444
000000000000012966aca980b406faa35b4c7abcc896846794f2c3f6f9b63aa0 225445

Zee blockchain killer 225430 (slush / 1MB):
http://blockchain.info/block/000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023

Current best of new branch:
http://blockchain.info/block/000000000000012966aca980b406faa35b4c7abcc896846794f2c3f6f9b63aa0
member
Activity: 112
Merit: 10
legendary
Activity: 4690
Merit: 1276
No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.
0.8 doesn't use BDB, so no amount of testing of that version would have found the problem, since the problem only exists in versions prior to 0.8.

Bitcoin is a protocol and is, so far, supposed to be designed to have forward and backward compatibility.  Thorough testing would include interaction of many version.  But what I actually meant is that it is a bit surprising that the BerkeleyDB backed versions where not tested to a maximum block size (which, as I understand it, is expressed as a #DEFINE, and which, again in my understanding, was not changed between 0.7 and 0.8.)

That said, Bitcoin is still young and 'experimental' and it is fully understandable that the resources necessary to do rigorous QA are not available.  I'm not volunteering myself...although Bitcoin has the potential to make me rich enough that I probably should be...

sr. member
Activity: 303
Merit: 250
Geez, what would have happened if the botnet threat was worse than we thought and the 0.7 chain couldn't outpace the forking 0.8? Join in the 0.8 fork?
legendary
Activity: 1596
Merit: 1100
"no amount of testing would have found this" is a bit strong.

It is a longstanding bug that has existed through bitcoin's history, but it is certainly not impossible to test for this condition.  testnet has many test cases embedded in the chain, and this bug trigger certainly could have been one such test case.

Water under the bridge...  Satoshi had zero test cases in this original software.  Gavin and gmaxwell led the charge to start adding unit tests, and testnet blockchain tests.  BlueMatt has been working on a block tester as well.

420
hero member
Activity: 756
Merit: 500
so it's solved it seemed. what'd i miss? just waiting for the rest of the pools to downgrade?
sr. member
Activity: 462
Merit: 250
The pools with late .7 version are fine correct?

Can someone list all the pools that are affected?

I know OZCOIN was one, but the operator quickly shut down its mining.
full member
Activity: 210
Merit: 100
The price would not have rebounded so dramatically if mt gox had maintained bitcoin deposits. For every one person who wanted to sell and had coins in gox and then did sell, pushing price down to 35, there were probably at least 10 who keep their coins outside gox who were unable to sell theirs.

I actually agree that the devs handled this well and that their response is an inspiration more than anything, but the bad press tomorrow combined with the flood of (largely ignorant) sell orders once mt gox reopens deposits will certainly push the price down at least a bit.



legendary
Activity: 1400
Merit: 1013
No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.
0.8 doesn't use BDB, so no amount of testing of that version would have found the problem, since the problem only exists in versions prior to 0.8.
sr. member
Activity: 382
Merit: 253
I think I kinda understand why this is a good thing, but can you explain like I'm five? Basically, why would it have been bad to let the 0.8 chain continue?

Is the reason that it'd "force" older users to upgrade and that's a mean thing to do?

The main reason I see to go back to 0.7 instead of forcing upgrades to 0.8 is the size of the total mining pool. It should be easy for miners on 0.8 to fall back to previously used software - presumably they've all used 0.7 in the past. But miners who haven't upgraded yet haven't tested their systems on 0.8 and all manner of problems could occur making that take a long time. So we would end up with a significantly smaller amount of miners.
sr. member
Activity: 310
Merit: 250
anyway that chat log can be shared? I know a lot of people would love to read it.

 - http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12  

There might have been a couple reports of issues on the 11th.  The times are UTC so this starts on the 12th.

thank you sir!
legendary
Activity: 1008
Merit: 1023
Democracy is the original 51% attack
Yes, fixed now.
Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain


Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?


I think we should all contribute to the Devs beer and holiday fund, is there an address for this??

I don't have any mining hardware currently, but I want to contribute to the cause so I'm doing the hash algorithms by hand with pencil and paper. I then scan with OCR and email it into the blockchain.

I know ASIC's are out and all, and each hash is taking me forever, but I know I'm helping at least a little bit.
legendary
Activity: 4690
Merit: 1276
...
I also agree that no testing of 0.8.0 could reveal the fault because the unknown fault was in 0.7.x

No amount of testing?  Really?  Seems like a slightly better than par proficiency with BerkeleyDB would have sufficed, particularly as the block size has been under relatively discussion.  Finally.  But I'm only going by what I know of the issue by skimming.

So the cautious approach of not updating paid off this time.

In my case it's more laziness than caution.  I've not built 0.8x yet and I fear that when/if I try it still won't have a functional configuration system and I'll again have to hack in the #includes I need.  But I'm not mining so it's a mute point anyway.

legendary
Activity: 1400
Merit: 1013
Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?
If you're not mining there is nothing you can do to help, and there's no reason to downgrade to 0.7 if you already upgraded earlier.
legendary
Activity: 1246
Merit: 1002
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.

What do you call a spymaster who spies on his own spies?
Prudent.
full member
Activity: 154
Merit: 100
Yes, fixed now.
Fixed as in the chain containing the large block is now officially orphaned?

No, the 0.7 chain is still at 225441 while the 0.8 chain is 225453. Even worse, someones are stilling mining on the 0.8 chain


Is there any way us mere mortals without minig rigs can help? if we all come online with version 0.7 will it help or just create excessive traffic?


I think we should all contribute to the Devs beer and holiday fund, is there an address for this??
Pages:
Jump to: