Pages:
Author

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

pvz
newbie
Activity: 53
Merit: 0
... 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 prefer that the big/most miners have the same setup (old + new version + fallback to old version).

Let me rephrase: It seems 'tested' clients are not always backwards compatible. Why not give the best test there is (real life situation) to a new version with the best fail-save there is (the previous/old version).
sr. member
Activity: 406
Merit: 250
LTC
Whoever has an accout on arstechnica, please comment there, tell that event is over.
sr. member
Activity: 406
Merit: 250
ALGORY.io Crowdsale starts on 8/12/2017
It was fascinating to watch the higher block chain continue to build.  Was it ignorance by some large miners?  Or was it an intentional attempt to keep the blockchain forked.

No, it was night. I woke up at 3am thanks to one guy who called me over skype. I have a lot of monitoring scripts which trigger SMS alert when something bad happen on pool, but there was almost no chance to catch this, because the bug wasn't in bitcoind 0.8 used by the pool, but in previous (and still widely spread) bitcoind 0.7.

It is afternoon here. GMT+8 Smiley
hero member
Activity: 887
Merit: 1000
Block 225455  Grin glad were all on the same chain now! Even more glad the price didnt plummet.

Thanks in part to the fact that noone could move BTC's into gox. :p
legendary
Activity: 1204
Merit: 1000
฿itcoin: Currency of Resistance!
legendary
Activity: 1386
Merit: 1097
It was fascinating to watch the higher block chain continue to build.  Was it ignorance by some large miners?  Or was it an intentional attempt to keep the blockchain forked.

No, it was night. I woke up at 3am thanks to one guy who called me over skype. I have a lot of monitoring scripts which trigger SMS alert when something bad happen on pool, but there was almost no chance to catch this, because the bug wasn't in bitcoind 0.8 used by the pool, but in previous (and still widely spread) bitcoind 0.7.
hero member
Activity: 868
Merit: 1000
plz some one remove the warning at the top of the website it mite as well read "panic panic panic sell sell sell!"

+1
legendary
Activity: 883
Merit: 1005
plz some one remove the warning at the top of the website it mite as well read "panic panic panic sell sell sell!"
hero member
Activity: 607
Merit: 500
Block 225455  Grin glad were all on the same chain now! Even more glad the price didnt plummet.
everyone can make a little fortune by betting on panic Wink
member
Activity: 98
Merit: 10
newbie
Activity: 50
Merit: 0
while this does not undermine BTC conceptually - it does open up potential, future snags of a similar nature - e.g. another sw glitch occurring with some other 3rd party component the client is using or the code itself....

since its of paramount importance this never or infrequently happens - can the devs write some integration & unit tests that push the client and its dependencies to its limits as far as the devs can see them at this point and let these tests rip on a continuous basis? I could be wrong but it sounds like this BDB issue might've been detectable... I know this kind of exhaustive testing isn't easy or even possible but given how important BTC is to the future of the USA or the world possibly.... maybe special effort should be made to the greatest extent possible to alleviate any future snafus that would give critics fodder to "rip" Bitcoin apart ....

At any rate, I'm glad the concept so far is proving out to be solid and I hope these kind of snafus happen far less often in the future.
legendary
Activity: 1400
Merit: 1013
This all started when the lead developer issued an "off the cuff" suggestion to enlarge the block size from 250K to 500K.  A miner went the extra step and enlarged the block to 1M, which *should* have been legal.  But there wasn't enough system and integration testing.  [There was *none* as far as I can tell with respect to this suggested change.]  Perhaps the community will learn to avoid untested changes in the future.
It wasn't the size of the block that caused the problem.

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  
hero member
Activity: 868
Merit: 1000
Apparently from what I read, this was handled extremely well. My respect to the devs.
hero member
Activity: 669
Merit: 500
v 0.8 has now processed 225455
legendary
Activity: 2142
Merit: 1010
Newbie
Asking miners to volentarily change to a different version of the client software for the good of the network = "51% attack"?  Really?  That is your tortured definition.   

Well... Seems u r right. I hope similar scenario won't be used with political purpose though.
hero member
Activity: 784
Merit: 1000
Is this issue fixed or do we still have 2 blockchains running?

Fixed? U call 51% attack organized by Bitcoin Foundation "a fix"? :facepalm:

What 51% attack?  Do you even know what "51% attack" means?  Hint: it isn't the Bitcoin equivalent of the boogeyman.

Isn't there written about 51% attack?

  • If you're a miner, please do not mine on 0.8 code. Stop, or switch back to 0.7. BTCGuild is switching to 0.7, so the old chain will get a majority hash rate soon.

It's not an attack if nobody is stopping you from making transactions or getting confirmation, but just for you own safety, you need to wait out a bit longer, like wait for 30 something confirmations, etc.
newbie
Activity: 53
Merit: 0
This has been interesting to read.  The problem has almost corrected itself, and may be corrected by the time I press "submit".

Users never needed to downgrade.  Miners didn't really need to downgrade either.  They needed to stop producing very large blocks.  And they needed to be poked to ignore the higher block, temporarily.  [Downgrading accomplishes both, but I doubt that most miners went to that trouble.]

This all started when the lead developer one of the developers issued an "off the cuff" suggestion to enlarge the block size from 250K to 500K.  A miner went the extra step and enlarged the block to 1M, which *should* have been legal.  But there wasn't enough system and integration testing.  [There was *none* as far as I can tell with respect to this suggested change.]  Perhaps the community will learn to avoid untested changes in the future.

What prompted the suggestion to enlarge the block size?  A single site comprises some 70%+ of the traffic on bitcoin.  They are growing by leaps and bounds as bots are now doing the betting.  Whether you think SD was the "hero" for helping this bug come to light or the "villian" whose actions brought about the "off the cuff" remark and the ultimate fork is your call.  [There is plenty of heat in other threads, so let's please keep that argument out of this thread.]

It was fascinating to watch the higher block chain continue to build.  Was it ignorance by some large miners?  Or was it an intentional attempt to keep the blockchain forked.  Theoretically, this could have been fixed hours ago.  But I saw some well-known pool operators working on the chain that had (by consensus, apparently) been decreed to be the loser of the race.

Fun times.   Smiley

member
Activity: 72
Merit: 10
Block 225455  Grin glad were all on the same chain now! Even more glad the price didnt plummet.
donator
Activity: 1218
Merit: 1079
Gerald Davis
Asking miners to volentarily change to a different version of the client software for the good of the network = "51% attack"?  Really?  That is your tortured definition.   

How about the real one ...
https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power

Quote
Attacker has a lot of computing power
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:
Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks
sr. member
Activity: 291
Merit: 250
well, one more until it re-orgs for me
Actually it looks like it orphaned the bad 225454 block. G'nite!
Pages:
Jump to: