makomk
|
|
March 12, 2013, 12:08:06 PM |
|
It's actually about half of that. About half of those people shouldn't have found blocks and only did because the person who should have mined the block was working on the other chain.
Think about it this way, for each block in the fork, someone mined the block in the 0.7 chain and someone mined it in the 0.8 chain. About half the time, the right person got it (because the forks merged when the work in them was roughly equal), and they still have it. About half the time, the wrong person got it and the right person lost it in an orphaned block.
That's not true. Think about it this way - the difficulty didn't change, so on average everyone mined about the same number of blocks as they would have if the blockchain hadn't forked, except that all the blocks on the losing side of the fork were orphaned and the people mining them didn't get paid. If it wasn't for the fork the blocks would have been distributed slightly differently amongst the miners on the losing side and they might have received very slightly more or less, but since it could vary in either direction we can safely say they're out 625BTC or 29k$. (This also means all miners on the losing side of the fork lost money even if none of their blocks were orphaned, since they could potentially have mined blocks if the chain hadn't forked.)
|
Quad XC6SLX150 Board: 860 MHash/s or so. SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
|
|
|
becoin
Legendary
Offline
Activity: 3431
Merit: 1233
|
|
March 12, 2013, 12:12:52 PM |
|
The only question is when does it happen and who will lose out because of it. The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork?
|
|
|
|
trainhappy
Member
Offline
Activity: 66
Merit: 10
|
|
March 12, 2013, 12:15:38 PM |
|
Would you all calm down.... This issue only affects miners and merchants. I'm not a miner or a merchant, what should I do? Nothing. Your bitcoin software will switch to the correct chain automatically, no matter which version you are running. - http://bitcoin.org/chainfork.htmlTransactions are going through fine according to https://coinbase.com/network its not the end, so just relax....
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
March 12, 2013, 12:18:07 PM |
|
The only question is when does it happen and who will lose out because of it. The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork? The longer one would have won. Depending on how much power is already at the new clients, this could have disabled the old clients from the network - made them obsolete. Which maybe would have been a good thing, considering that this needs to happen anyway, if we don't want to wait weeks for our transactions to get mined, in a month time or so.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
chooser
Newbie
Offline
Activity: 13
Merit: 0
|
|
March 12, 2013, 12:18:29 PM |
|
To be accurate, it wasn't "the lead developer" who suggested raising the block size limit, it was me. I am a Bitcoin developer, but Gavin is the lead. So you can blame me if you like.
Thank you for rising the block size limit. This is something that had to be done. Thanks to you we know this issue and now we can expect that it will be done in a safer way in the future. Moreover we all know that we're using an experimental currency, and funny things might happen.
|
|
|
|
benjamindees
Legendary
Offline
Activity: 1330
Merit: 1000
|
|
March 12, 2013, 12:20:13 PM |
|
By definition, a *unexpected* difference in behavior between the old client and the new client is a bug in the new client.
Props to everyone who recognized this and did the right thing to correct it. This only strengthens my faith in Bitcoin. How can we prevent this from happening in the future and is there any other way the average user can contribute to the robustness of bitcoin?
Keep your software updated. Terrible advice for a project like Bitcoin. From what I can gather it seems to me like the database used by 0.8 is much more superior, so it will be used. But in order to patch 0.8 it seems like an artificial cap will be placed on the block size so that 0.8.1 is compatible with older versions.
This sounds like the way forward.
|
Civil Liberty Through Complex Mathematics
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
March 12, 2013, 12:25:11 PM |
|
The only question is when does it happen and who will lose out because of it. The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork? The longer one would have won. No. A majority of miners cannot effect a change in protocol rules. A hard fork like this would require the intentional support of a majority of merchants. Short of an emergency, that means everyone will be given at least 2 years to upgrade.
|
|
|
|
arruah
Legendary
Offline
Activity: 1357
Merit: 1004
|
|
March 12, 2013, 12:29:09 PM |
|
Please explain to me whether I'm on my pool is now updated to version 0.8?
|
BCH
|
|
|
PawShaker
|
|
March 12, 2013, 12:35:33 PM |
|
The only question is when does it happen and who will lose out because of it. The really important question is what would have happened if there wasn't a coordinated effort to help the "correct" fork? It is important to keep in mind that this kind of problems are rare and have been already been thought about. Bitcoin as whole is resilient against this kind of problems. When two versions of Bitcoin nodes cannot agree on interpretation of the rules then miners vote with their feet. They either upgrade or downgrade. The only thing interesting about this incident is that a small group of most potent miners have changed the outcome by dumping their version. It seems that at the beginning version 0.8 was winning and everyone would be forced to upgrade to that version on very short notice. Only when operators of big pools decided to downgrade, branch on which version 0.7 worked took over. The issue got everyone by surprise mainly because old version (0.7) had a surplus rule/feature limiting block size. Was problem known before, developers would first release a version which accepts large blocks but does not produce them. Only when almost everyone would upgrade to that version, large blocks would be produced. Actually this is what we are having now. Version 0.8 with default configuration accepts large blocks but does not produce them.
|
1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
March 12, 2013, 12:35:42 PM |
|
A hard fork like this would require the intentional support of a majority of merchants.
Sure. But how is it unintentional to accept blocks longer than 250KB, after the "majority" (expressed in the hashing power) upgraded their clients to a version that accepts blocks larger than 250KB? And they upgraded it not because they had no reason - they actually had a very good reason.
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
FreedomCoin
|
|
March 12, 2013, 12:38:40 PM |
|
i have a bunch of unconfirmed bitcoins when i reverted back to 0.8
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
March 12, 2013, 12:39:32 PM |
|
i have a bunch of unconfirmed bitcoins when i reverted back to 0.8
did you try to start it with "-rescan"?
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
FreedomCoin
|
|
March 12, 2013, 12:47:01 PM |
|
i have a bunch of unconfirmed bitcoins when i reverted back to 0.8
did you try to start it with "-rescan"? How do i do a -rescan? Yesterday after downgrading to 0.7 i got a cannot read blkindex.dat... now that i reverted back to 0.8 now more than half of my wallet is unconfirmed. should i delete the blkindex.dat and the blk000x.dat files?
|
|
|
|
piotr_n
Legendary
Offline
Activity: 2053
Merit: 1354
aka tonikt
|
|
March 12, 2013, 12:51:46 PM |
|
How do i do a -rescan?
when you start bitcoin-qt (or bitcoin-qt.exe) add -rescan to the command line. it will take much longer to start, but all the transactions inside your wallet should eventually appear confirmed, assuming that you see them confirmed at i.e. http://blockchain.info/
|
Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E
|
|
|
benjamindees
Legendary
Offline
Activity: 1330
Merit: 1000
|
|
March 12, 2013, 12:56:49 PM |
|
So what is the procedure for those (regular users) who want to continue using 0.8.0 without causing issues? Is there a database config variable to set or something?
Downgrading seems like a bad idea for regular users.
|
Civil Liberty Through Complex Mathematics
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
|
March 12, 2013, 12:58:20 PM |
|
So what is the procedure for those (regular users) who want to continue using 0.8.0 without causing issues? Is there a database config variable to set or something?
Downgrading seems like a bad idea for regular users.
Don't downgrade. You aren't a concern unless you are a miner.
|
|
|
|
BRules
|
|
March 12, 2013, 12:59:33 PM |
|
regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.
|
|
|
|
FreedomCoin
|
|
March 12, 2013, 01:05:03 PM |
|
regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.
I thought miners "were" suppose to downgrade, but now the issue has been addressed.
|
|
|
|
FreedomCoin
|
|
March 12, 2013, 01:06:30 PM |
|
How do i do a -rescan?
when you start bitcoin-qt (or bitcoin-qt.exe) add -rescan to the command line. it will take much longer to start, but all the transactions inside your wallet should eventually appear confirmed, assuming that you see them confirmed at i.e. http://blockchain.info/that fixed it, thanks for the tip... though do i need blk0001-3.dat? theres 3 files each being 2gb.
|
|
|
|
niko
|
|
March 12, 2013, 01:07:29 PM |
|
regular users don't need to do nothing, only miners should downgrade or should not increase the target block size from the default.
Given the bdb bug, I would say miners need to upgrade to 0.8, but should not increase the blocksize (or make any changes, for that matter) until everyone has upgraded, and until more testing is done.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
|