Topic: Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks - page 14. (Read 155564 times)
March 12, 2013, 01:19:52 AM
I there was going to be fireworks??
March 12, 2013, 01:19:26 AM
well, one more until it re-orgs for me
ok, there
2013-03-12 06:20:30 received block 000000000000016924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:30 REORGANIZE: Disconnect 25 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 0df96f272c3b1e9dd15272b55750966cbd239219b94756c73ec
2013-03-12 06:20:30 REORGANIZE: Connect 26 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 16924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:34 Committing 28586 changed transactions to coin database...
ok, there
2013-03-12 06:20:30 received block 000000000000016924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:30 REORGANIZE: Disconnect 25 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 0df96f272c3b1e9dd15272b55750966cbd239219b94756c73ec
2013-03-12 06:20:30 REORGANIZE: Connect 26 blocks; 0000000000000366ce98ca28338900094e8cbf445776253181749f782546d006..0000000000000 16924f85069603be8164578eedf113f44d60bf0438cba047c7f
2013-03-12 06:20:34 Committing 28586 changed transactions to coin database...
March 12, 2013, 01:18:59 AM
Phew!
Nice work everyone. This really shows the resilience of bitcoins.
Nice work everyone. This really shows the resilience of bitcoins.
March 12, 2013, 01:18:19 AM
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.
March 12, 2013, 01:17:57 AM
If we use blockchain.info wallet, I guess we don't have to worry.
Will Multibit be affected?
MultiBit should be able to handle re-orgs of depth 50, so I guess you are fine. Will Multibit be affected?
March 12, 2013, 01:16:54 AM
Come on... Stop panicking. It's a okay.
March 12, 2013, 01:16:26 AM
If we use blockchain.info wallet, I guess we don't have to worry.
Will Multibit be affected?
Will Multibit be affected?
March 12, 2013, 01:16:06 AM
March 12, 2013, 01:15:35 AM
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.
March 12, 2013, 01:15:34 AM
0.7 is catching up??
March 12, 2013, 01:14:18 AM
Is this issue fixed or do we still have 2 blockchains running?
Fixed? U call 51% attack organized by Bitcoin Foundation "a fix"? :facepalm:
March 12, 2013, 01:14:15 AM
Bam!
March 12, 2013, 01:14:03 AM
Is this issue fixed or do we still have 2 blockchains running?
Looks like 1 or 2 blocks and the fork will be fixed.
March 12, 2013, 01:12:13 AM
Is this issue fixed or do we still have 2 blockchains running?
March 12, 2013, 01:12:00 AM
Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?
There's no sane way to enforce timestamps. Say someone mines a block that you think has a time three minutes in the future, what do you do? Do you ignore it? Do you deliberately set your time even further in the future and try to mine a block with a time you believe is wrong?Please explain how the timestamp of block 225449(2013-03-12 05:30:02) is before block 225448(2013-03-12 05:33:45)?
It is permitted within the spec that one block may set its 'nTime' field before a previous block... but always within a certain range of time.
Correct?
March 12, 2013, 01:11:47 AM
If you'd like to contribute, testing is an area where we can basically have an infinite amount of additional resources and put them all to good use.
If I set up a node on testnet to CPU mine and just left it would that be helpful, or does it need to be monitored? 
March 12, 2013, 01:10:07 AM
Damn, Bitcoin is so kickass resilient. I want to see how Mastercard, Visa or Amex would manage to fork a network problem into another dimension and continue processing transactions as if nothing happened while the network self organizes to route around the issue. That accident could seem like negative PR for Bitcoin, but by the time the dust settles, bystanders can only be impressed by the insolent lack of consequences of this global network outage.
Indeed !
Very true.. Im also quite impressed about BTC resilience
March 12, 2013, 01:09:55 AM
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.
If you'd like to contribute, testing is an area where we can basically have an infinite amount of additional resources and put them all to good use.
March 12, 2013, 01:09:00 AM
1 more until matched. 2 until reorg.
March 12, 2013, 01:08:50 AM
Difficulty is adjusted every ~2000 (ed2: 2016... I think. hah) blocks. I suppose some people could keep going on the orphaned side, but it won't matter anymore (after this pre 0.8 side catches up)....
Wouldn't happen. The 0.8 miners will immediately notice that the 0.7 chain has become the main chain and will switch to it. One of them could still produce another problematic block, but it would just be an ordinary orphan, not a fork. Jump to: