Pages:
Author

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

full member
Activity: 354
Merit: 103
Don't panic guys didn't you know the white nights who say Ni, has come from Wall St. (tm) to help us :-)

hero member
Activity: 492
Merit: 503
Just writing here to make part of history. "I WAS THERE" when Bitcoin shows the 2nd high level bug!  Grin



+1. So sue me.
hero member
Activity: 686
Merit: 500
Bitbuy
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

So the difference increased from 11 blocks to 12 blocks? =/
legendary
Activity: 1008
Merit: 1023
Democracy is the original 51% attack
I personally am surprised and delighted that we move in this direction (back to the universal fork as trunk) rather than force an upgrade. 

So am I.

I thought only once banks or governments start cracking down on Bitcoin we will appreciate Bitcoins's capability of graceful degration [http://en.wikipedia.org/wiki/Fault-tolerant_system] but it only took a flaw to proove that it has that capability.

My deep respect for the devs who took this issue on and solved it. You guys made Bitcoin and my believe in it even stronger.

To blockchain eternity!

Joe



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?
legendary
Activity: 1792
Merit: 1111
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
legendary
Activity: 2506
Merit: 1010
All transactions already have been reprocessed on new fork. [/iquote]

Has this been confirmed?  If so, source?

In fact the very first few blocks on new branch should contain all transactions in old branch.[...]The threat of double spending is theoretical, because when fork occurred there were miners working on both branches.

Sure the v0.7 nodes could have known of the transactions but there were fewer v0.7 blocks and the contents of the blocks were different from the v0.8 mined blocks.

I'm not expecting that this happened, but some of the new nodes that downgraded from v0.8 wouldn't yet have those "not-yet-onfirmed-in-v0.7" transactions in their memory pool, which opens a truck-sized hole for someone attempting a race attack.  

So I'lm not sure I'ld call it a "theoretical" risk.  If there was one or more successful double spends as a result I wouldn't be surprised, and had someone prepared in advance for this and had perfect timing and good luck, significant losses for a couple exchanges could have been the result.
sr. member
Activity: 359
Merit: 250
I personally am surprised and delighted that we move in this direction (back to the universal fork as trunk) rather than force an upgrade. 

So am I.

I thought only once banks or governments start cracking down on Bitcoin we will appreciate Bitcoins's capability of graceful degration [http://en.wikipedia.org/wiki/Fault-tolerant_system] but it only took a flaw to proove that it has that capability.

My deep respect for the devs who took this issue on and solved it. You guys made Bitcoin and my believe in it even stronger.

To blockchain eternity!

Joe

legendary
Activity: 1008
Merit: 1023
Democracy is the original 51% attack
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.
paid shill?

Wouldn't be the first time people called me that.
legendary
Activity: 1400
Merit: 1013
Yes, fixed now.
Fixed as in the chain containing the large block is now officially orphaned?
legendary
Activity: 1246
Merit: 1077
Am I correct that we will need upgrades for every version of the Bitcoin client, because 0.7 and lower throw exceptions when parsing any block that breaks the DB? Could this be used as a DOS attack?

So that means the versions to upgrade to will be:

0.8.1, which somehow simulates the bug in 0.7 and lower.
0.7.3, which stops throwing the exception and flat out rejects the blocks the bug breaks.
0.6.5, as 0.7.3
0.6.0.11, as above
0.5.8, as above
0.4.9, as above
0.3.25, as above

I assume there will be no need to upgrade 0.2 or below.
sr. member
Activity: 444
Merit: 250
I prefer evolution to revolution.
Yes, fixed now.  You can see the sequence of orphaned blocks on blockchain.info if you want.
newbie
Activity: 42
Merit: 0
Is this where the "EXCEPTION:11DbException Db::put: Not enough space" message comes from?

Do I need to do anything on my non-mining client to fix things, or will it auto-fix itself soon?

i have same problem  and seem to be stuck on block 225441

full member
Activity: 238
Merit: 100
This could have really forked my day if it wasnt fixed  Smiley
legendary
Activity: 1946
Merit: 1006
Bitcoin / Crypto mining Hardware.
0.8 is not flawed. The flaw lied in 0.7 and below. If an upgrade was hastened, the problem would not have been a problem at all.
Sadly, 0.8 is flawed— its "one job" was to faithfully follow the behavior of 0.7, "bugs" and all. It did not. Had we known about this behavior in 0.7 or had testing turned it up we would have made sure 0.8 behaved the same way.

This is the nature of a distributed consensus system.  The primary definition of right and wrong is "consistent" and if you aren't consistent you aren't right, no matter what.


The testing should have happened with the older version of Bitcoin. I don't see how testing 0.8 would fix this issue, given that 0.8 fixes the bug.
+1
legendary
Activity: 1512
Merit: 1049
Death to enemies!
Quote
I agree that he nailed it.  The problem is that he proposed a solution that wasn't necessary.  This is like the CEO who says the product has to go through another full QA cycle, costing the company another $350,000 instead of letting the possibly buggy code out because the devs know that the average 200 bugs cost about $25,000 to fix.  We don't bother spending the extra $325,000 just to please a CEO.
With Bitcoin we as a community cannot take unnecessary risks. We can probably risk producing buggy code for Space Shuttle or automatic nuclear missile launch systems, but not with Bitcoin.

Atlas main concern was different back then (ultraprune implementation and possibility to break it) but he still was right about fundamental database engine changes who might cause trouble.

I also agree that no testing of 0.8.0 could reveal the fault because the unknown fault was in 0.7.x

So the cautious approach of not updating paid off this time.
sr. member
Activity: 252
Merit: 250
Coinlancer.io ICO | Oct 14th
legendary
Activity: 2506
Merit: 1010
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.
copper member
Activity: 1428
Merit: 253
This is the developer responsible for all this mess!!!

Pages:
Jump to: