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

Just a question - what would happen if the split was catched too late, allowing to get 100 confirmation for split-mined block to mature? Does it play any role, or just even larger reorg, like several hundred blocks, is still doable (with not too harsh consequences)?

Eligius makes blocks, that was the point.

0.7 need not be ditched. Just tell everyone that after a certain date/block everyone must accept all valid blocks, whether by using 0.8 client or by configuring their databases so that an earlier client accepts them.

However, as it's by definition a hard fork, other hardfork-requiring changes to the protocol could be implemented at the same time. And THIS would most likely require everyone to upgrade.

Well, yes and no.  True, if 90% had upgraded before the fork, the decision would probably have gone in their favour.  But the real problem was an unexpected incompatibility between versions.  There are (rarely) planned forks, and this was an unplanned fork.  Slush's pool didn't create the incompatible block because they believed a majority ran 0.8, they did it because they believed a large majority ran a version that would accept it.

This sort of crippling would be impossible given the circumstances (no central control, open source).  The best that you can do is urge users to upgrade... or downgrade, as the case may be.  ("rightgrade"?)

Then we are in violent agreement!  Hooray!

All true, but I suspect you underestimate the, uh, conservatism that makes "the network ditching 0.7" non-trivial.  That may end up being the chosen way out, and Deepbit, Eligius, etc., will plan to upgrade at an appointed time.  Or another solution may emerge.  We've waited months for 0.8, and we can afford to wait a few more days or weeks, though the newly discovered 0.7 bug adds a reason to move.

If there was a way of limiting the work being done network wide if you have an outdated miner/client. Forcing updates to bring hashes back up.

The older version after it expires it works like crippleware. I'm just giving a new perspective on solutions. I'm by no way anyone who understands this as an expert. If I'm understanding this correctly the transition to 0.8 was to slow right?

If that's the case then by crippling the older version and forcing the timely update would prevent older versions from competing with new versions and incentive's people on older versions to update quickly. Preventing a fork.

I could be wrong.

That was my point actually. I was not accusing the developers of negligence I was saying that his platitudes are a form of "I could have done it better then them if I was them and could see the future". Well, he isn't them and they didn't see the future.

If the network ditches 0.7 then there is no problem.
As long as the network is predominantly 0.7 this would result in you creating a single orphaned block rather then a fork. While certainly a waste, this could happen while using 0.7 to mine as well (for a different reason).

@taltamir

Let's slow down and think this through, shall we?  You claim:


Unfortunately, this statement glosses over a crucial detail.  In scenario A, as I understand, you mean "force most 0.8 miners to reject valid blocks which it predicts 0.7 cannot process".  And you are correct, currently I know of no way to do this.

Whereas, in B, you must force all nodes to refrain from generating blocks like the one that caused this incident.  Otherwise, in a


someone could start a fork the same way as just happened.  Do you see?  It's the all part that makes us reject your proposal B in the short term.  Neither A nor B is workable as of now.  Block generators are advised to use 0.7 or earlier.  As long as most do, we (probably) avoid this kind of a fork.

I don't know why the forum banner still claims that mining on 0.8 is OK.  Miners using 0.8 risk wasting hashes by building on a block that the majority (0.7-compatible network) will reject.  Perhaps someone who has followed on IRC can comment?


Pipe down, I am sure the developers thought long and hard about ways that 0.8 might cause a fork.  One slipped through, because accidents happen.


I agree with you, it is a big issue, and I feel confident that the core developers and stakeholders will find a reasonable solution pretty soon if they haven't already.

I am not talking about being on the safe side, I am talking about the general consensus what should be done or not done. Without patching anything.

Stay on 0.7 or move to 0.8 if you are _making_ blocks?

Eligius is on 0.6 and 0.8 and it had 0 problems.

Maybe you should go back to 0.6 to be on the safe side.

Just to be clear, if you are making blocks you should stay on 0.7 for the time being or is it time to upgrade?

For somebody that was hiding behind a rock for the past few weeks it's a bit confusing with so many conflicting statements over the past few days (and especially the first day or two).

What about b. with an expiry date of say 60 days?
So 0.8.1 is released compatible with the predicted behavior of 0.7, and miners are asked please upgrade to it within the time period offered.

Whether you:
a. force 0.8 to reject valid blocks which it predicts 0.7 cannot process - currently cannot be done
b. force 0.8 to not generate blocks which it predicts 0.7 cannot process - currently can be done

The result is the same, you avoid a fork.

The issue is that option A is stupid and not doable. You would need to create a new version with a special block rejection engine to arbitrarily reject valid blocks predicted to be rejected by the bugged v0.7.
While for option B you simply have to alter the configuration of 0.8

And keep in mind that in reality you will see a mixed environment of 0.7, 0.8 unmodified, 0.8 with option B.
Bitcoin is without central authority and with people voting by implementing whatever solution they want, if any (meaning there are going to be many people who implement NEITHER solution)
As a miner, using 0.8 with option B gives you the lowest chance to generate an orphan block. followed by using 0.7 and then by option A


That would mean continuing to use 0.7 is an even bigger issue.

I remember reading not every 0.7 node rejected the block, and the behavior was not even consistent within a same node; some nodes would accept the block after being restarted after initially rejecting it.

That would mean that 0.7 nodes are capable of producing blocks that other nodes of the exact same version may or may not accept, depending on factors which are hard to predict.

Did 0.7 generate blocks that 0.7 rejected?

I put a proposal for that in a new thread.

It will never, ever matter which blocks can be generated in regard to forking.

What matters is what blocks are accepted and what blocks are rejected. If this is consistent, no forks will happen. If this is inconsistent, a block accepted by one but rejected by the other is very likely to cause a fork if the ones that accept have the majority of hashing power. The ones that reject will then be permanently split off.

With bank accounts, consistency in transactions is far more important than avoiding minor bugs in implementing the specifications that don't affect the consistency or correctness of the transactions. This is why they made the decision to switch the mining pools to 0.7 for now. This gives the vast majority of hashing power to a universally-consistent chain.

They can set a date and time for everyone to switch to accepting 0.7-incompatible blocks. Then we'll again be consistent (as far as this problem), though people will be out of luck if a fork happens, until they upgrade.

But the thing is they'd set a date to switch over what block-producers will accept, not what they produce.

People end up on whichever fork is longest and the mining pools will outpower anything else, leaving you on the right fork...as long as you can accept what the mining pools put out.

If you use a 0.7 client, that'll work only until the mining pools switch to 0.8, produce another incompatible block, and leave you on the wrong fork.

If you use a 0.8 client, that'll work now and after the switchover.

So, if you're not submitting newly-mined blocks, you should use 0.8.

it obviously did, but with the entire network rejecting said blocks they caused orphans instead of a fork.

Is that so? so why didn't it happen ever before?