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

tvbcof

legendary

Activity: 4690

Merit: 1276

Quote from: Mike Hearn on March 12, 2013, 05:08:26 AM

...

Also, I'm afraid it's very easy to say "just test for longer" but the reason we started generating larger blocks is that we ran out of time. We ran out of block space and transactions started stacking up and not confirming (ie, Bitcoin broke for a lot of its users). Rolling back to the smaller blocks simply puts us out of the frying pan and back into the fire.

We will have to roll forward to 0.8 ASAP. There isn't any choice.

I would like to understand with better precision what you mean by this. Can you point to a particularly enlightening bit of documentation or discussion about this issue?

From your brief description, it seems to me that this is one of the most show-stopper of deficiencies in Bitcoin design.

This because no matter whether the block chain remains small and universally accessible, or grows huge and accessible only to those with state of the art data processing systems, it can always be expected that we run up against block size limits at certain time periods. If doing so causes a 'blood clot' in the system, it seems to me that a high priority line of development should be in figuring out how to dismiss the stagnant transactions such that they don't cause ongoing issues.

I cannot see switching to a more efficient database being anything but an uphill foot-race which will ultimately be lost even if Bitcoin evolves to a situation where it is only run by cluster-type 'supernodes' with fat pipe connectivity and the blockchain in RAM. Even if we do go this direction, sorting out the 'backed up transactions' issue while the system is yet small seems like a good idea.

ProfMac

legendary

Activity: 1246

Merit: 1002

Quote from: Raoul Duke on March 12, 2013, 10:28:03 AM

Quote from: SgtSpike on March 12, 2013, 10:12:03 AM

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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.

Is there a link to "the best" thread to place the future SD impact discussion?

wtfvanity

hero member

Activity: 504

Merit: 500

WTF???

Quote from: jgarzik on March 12, 2013, 11:22:44 AM

Quote from: wtfvanity on March 12, 2013, 10:43:45 AM

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

The limitation is not related to block size, but rather number of transactions accessed/updated by a block.

In general, the default for 0.8 (250k) is fine. Raising that to 500k is likely just as fine.

But it is not very simple to answer the question, because this 0.7 BDB lock issue becomes more complicated with larger BDB transactions.

TY for the clarification.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: wtfvanity on March 12, 2013, 10:43:45 AM

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

The limitation is not related to block size, but rather number of transactions accessed/updated by a block.

In general, the default for 0.8 (250k) is fine. Raising that to 500k is likely just as fine.

But it is not very simple to answer the question, because this 0.7 BDB lock issue becomes more complicated with larger BDB transactions.

HappyScamp

sr. member

Activity: 314

Merit: 250

Thanks Peter for the info and the prominent posting!

DoomDumas

legendary

Activity: 1002

Merit: 1000

Bitcoin

Quote from: doobadoo on March 12, 2013, 11:01:29 AM

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!

And you still quote Eric in your sig ;P

doobadoo

sr. member

Activity: 364

Merit: 250

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!

ProfMac

legendary

Activity: 1246

Merit: 1002

Quote from: becoin on March 12, 2013, 03:48:39 AM

Quote from: cypherdoc on March 11, 2013, 10:13:11 PM

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.

wtfvanity

hero member

Activity: 504

Merit: 500

WTF???

Quote from: Luke-Jr on March 12, 2013, 07:25:11 AM

Quote from: piotr_n on March 12, 2013, 07:18:07 AM

Quote from: becoin on March 12, 2013, 07:12:52 AM

Quote from: Mike Hearn on March 12, 2013, 05:08:26 AM

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?

piotr_n

legendary

Activity: 2053

Merit: 1356

aka tonikt

Quote from: FreedomCoin on March 12, 2013, 08:06:30 AM

Quote from: piotr_n on March 12, 2013, 07:51:46 AM

Quote from: FreedomCoin on March 12, 2013, 07:47:01 AM

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.

Raoul Duke

legendary

Activity: 1358

Merit: 1002

Quote from: SgtSpike on March 12, 2013, 10:12:03 AM

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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.

Technomage

legendary

Activity: 2184

Merit: 1056

Affordable Physical Bitcoins - Denarium.com

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.

Schleicher

hero member

Activity: 675

Merit: 514

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.

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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.

Lethn

legendary

Activity: 1540

Merit: 1000

Quote from: Littleshop on March 12, 2013, 10:00:08 AM

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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.

Littleshop

legendary

Activity: 1386

Merit: 1004

Quote from: VinceSamios on March 12, 2013, 10:01:01 AM

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.

VinceSamios

sr. member

Activity: 448

Merit: 250

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

legendary

Activity: 1386

Merit: 1004

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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.

Severian

sr. member

Activity: 476

Merit: 250

Quote from: Jenger on March 12, 2013, 08:16:06 AM

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

BitcoinAshley

sr. member

Activity: 448

Merit: 250

Quote from: Raoul Duke on March 12, 2013, 08:47:34 AM

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 ;-)

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