Alert: chain fork caused by pre-0.8 clients dealing badly with large blocks

[Gabi]

Gentlemen, you just watched finance in the 21st century.

*complete transparency
*community driven
*solution driven
*results

Bitcoin just gained a lot more confidence.

Well said!

[1713399910]

1713399910

[1713399910]

1713399910

[1713399910]

1713399910

[FreedomCoin]

Gentlemen, you just watched finance in the 21st century.

*complete transparency
*community driven
*solution driven
*results

Bitcoin just gained a lot more confidence.

Well said!

YES! Well done, take that Fed Reserve. And BTC is still in the $40s

[Jenger]

So my question is who did this effect negatively & who took the hit because of this?

Someone had to lose a good amount of BTC yesterday.

[hgmichna]

And BTC is still in the $40s

Which is good only if it isn't just another bitcoin price bubble.

But we will see. If the price stays up here for another month then we can conclude that is was for real and not a bubble. I'm not exactly holding my breath though.

Bubble or not, bitcoin and its community, particularly the developers and miners, have weathered this technical crisis excellently. In the long run, this will have made bitcoin more resilient, because it shows to the world that both the technical foundation and the bitcoin community are sound and healthy.

[Raoul Duke]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

[juggalodarkclow]

397 posts in 12 hours?

[BitcoinAshley]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

Haha, no. If it weren't SD it'd be somebody else. What is the central Bitcoin authority that is going to force SD to change? We can each personally expect SD to change out of the kindness of their heart, but the reality is that using the blockchain in the way they're using it is currently profitable. Unless a combination of efforts make it not profitable (upping blocksize limit, letting tx fees price themselves in, miners refusing or delaying dust tx with no fee, etc) the problem will always exist. SD's current "abuse" simply means we have a more pressing reason to fix the problem. If they stop doing it, we probably won't fix the problem, and then someone else or a whole bunch of different sites will come along and start doing the same thing.

So you're advocating kicking the can down the road? Last I checked, this wasn't Obamacoin ;-)

[Severian]

So my question is who did this effect negatively & who took the hit because of this?

Someone had to lose a good amount of BTC yesterday.

> Eleuthria: ~1500 BTC lost in 24 hours from this

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

[Littleshop]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

Not at all.  Heavy network traffic found a true BUG the hard way.  While SD traffic exasperated the problem, the problem was there.  Better now to find the bug and fix it then when the increased traffic is coming from something like newegg taking bitcoin.

[VinceSamios]

I'm not sure if solutions have already been proposed for this issue, however surely a software update (v0.8.1?) could incorporate the following rule:

Limit block size or volume of transactions per block until < 10% of clients are running 0.7

The potential problem then is safeguarded against until a solid majority of users have upgraded to "fixed" software. Is neat, clean, quick, simple, future proof.

Eventually the same code could be removed from a client when < 1% of the network is running 0.7

No harm, no foul, no problems.

[Littleshop]

I'm not sure if solutions have already been proposed for this issue, however surely a software update (v0.8.1?) could incorporate the following rule:

Limit block size or volume of transactions per block until < 10% of clients are running 0.7

The potential problem then is safeguarded against until a solid majority of users have upgraded to "fixed" software. Is neat, clean, quick, simple, future proof.

Eventually the same code could be removed from a client when < 1% of the network is running 0.7

No harm, no foul, no problems.

Since this is a mining problem, not a client problem, it does not even need a new release.  Miners can run .8 right now with a parameter change and everything is fine.  When the network has enough nodes not running .7 they can change the parameter.  The big problem is e-commerce sites as there are a lot more of them and the change may break things (though it should not).  Those are the people that need to upgrade.

[Lethn]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

Not at all.  Heavy network traffic found a true BUG the hard way.  While SD traffic exasperated the problem, the problem was there.  Better now to find the bug and fix it then when the increased traffic is coming from something like newegg taking bitcoin.

This is really all that needs to be said about the whole situation, this is what open source is all about, if you don't like it, go back to paper money, it amazes me that people are actually bitching about someone actually using the currency a lot, I think SatoshiDice deserve praise for finding this problem.

[SgtSpike]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

Nope.

[Schleicher]

Ok, so now is the time to ask everyone to upgrade to 0.8, right?
I can't see any reason not to do it.

[Technomage]

Regular SD transactions are completely valid. They pay the fee, and pay more fees combined than everyone else who uses Bitcoin. There is a type of SD transaction that is very problematic though, which can be considered flooding. I think we can set up mechanisms to block those transactions, the blocksize issue shouldn't be mixed with that.

[Raoul Duke]

So, can we all agree that rushing things to take care of the volume of transactions that are mostly comprised of satoshidice spam isn't a good idea and it's SD who needs to change and not bitcoin?

Nope.

I'm not saying it shouldn't be fixed. Just saying that rushing fixes isn't the way to go, as can be seen from this major fuckup.

[piotr_n]

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.

if you are talking about the files from the main data dir (not in the "blocks/" subfolder) - you don't need these for 0.8
they were only used up to 0.7.x and while using 0.8 you can just remove them.

but to be sure, better close your bitcoin client, move the files to some temp folder, start the client and see if it still works fine - if it does, delete the files, otherwise restore them.

[wtfvanity]

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.

2 years according to who? Luke jr who is maintaining the older clients?

There are major advancements in version 0.8 and there is no reason that anyone should be wasting CPU and hard disk cycles when 0.8 is actually functional and older versions can't even keep up with the block chain. If 0.8 had been released 6 months ago, and we had twice as many people on 0.8, the scenario that might have played out would have been upgrade to version 0.8 because the only pools left on previous versions might just have been you lukey.

I don't see where it has been pointed out anywhere else, but it looks like it was slush's pool that made the original block at 225430. Then also had 5 more orphaned blocks. There were many blocks around 500 KB, it's the one at 974 KB that choked it.

So is anything over 250 soft limit not safe, or not over 500, or not over? Or has that not been determined yet?

[ProfMac]

why the hell is Deepbit only on 0.3.21 and Luke on 0.6.0?

I would like to ask this question as well.

Your bug icon is very disturbing.  I have finally trained myself not to try to squash it.

[doobadoo]

Its official, i guess SD just broke bitcoin.  Thanks eric, for all those unspendable outputs and massive block sizes.   I'm sure your apologists will claim that this event is good for bitcoin because we stress tested it.  Fuck that noise.  If it had taken longer to reach this point every one would have been running 0.8 or newer, the issue caused by old clients could not have happened.

I blame SD.  SD pushed our beta product way too far.  Shame on eric and his greedy little BS company.  I hope its stocks tanks.  I hope miners filter out the 1Dice.  Fuck that noise!