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

[markm]

I have seen it posted that 0.7 can itself produce blocks that some instances of 0.7 will reject; if that is the case it seems to me quite to be expected that 0.8 can too, even when using default settings, because I haven't heard that it ever really went out of its way not to produce just the very kind of blocks that 0.7 can produce that supposedly some 0.7's cannot handle.

I am not really all that sure yet though of the authoritativeness of the claims that 0.7 can actually produce 0.7-killers, at least not without a bit of code-hack-and-recompile shenanigans.

-MarkM-

[1715677401]

1715677401

[1715677401]

1715677401

[1715677401]

1715677401

[1715677401]

1715677401

[jgarzik]

I have seen it posted that 0.7 can itself produce blocks that some instances of 0.7 will reject;

That is true, though unlikely.

[Rarrikins]

The original post lacked info for "regular users".  Here it is:
...
Only miners have an incentive to do anything.

If you're talking to regular users, it doesn't make sense to talk about 'miners' in a way that implicitly doesn't include people who mine through pools, who obviously don't need to do anything since the pool operator will handle that.

[markm]

The use of the same term for hashers and people who actually validate and prepare blocks for hashing has been causing confusion all over the place for a while now.

Maybe clearer terminology is called for?

-MarkM-

[Rarrikins]

0.8 doesn't need to be taught to reject anything, the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier.
0.7 can actually CREATE blocks that it will itself reject due to that bug.

This is incorrect. The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected. They kept on going based on that block and the 0.7 clients kept on going based on other blocks.

What needs to happen is that 0.8.1 should be released where its the same as 0.8 only it changes the default CONFIGURATION such that it will NOT create 0.7- incompatible blocks.
When over 90% of the network are using 0.8+ this limitation can be safely removed and people using 0.7 or earlier will be forced to upgrade.

It doesn't matter if 0.8.1 doesn't produce incompatible blocks because solo miners are currently and will continue to use 0.8.0, which might produce those blocks (this is even if we assume that 0.7 can't produce those blocks). Then, all those 0.8.1 clients will accept the incompatible blocks and will fork from the 0.7 clients once again.

If you want to avoid forks like this, you need to ensure an acceptably-large majority of clients accept and reject the same set of blocks. I think this is best done by a scheduled hard fork, but I haven't thought too hard about it.

[taltamir]

the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier.

The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected.

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

[muyuu]

the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier.

The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected.

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

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

[taltamir]

the problem is 0.7 and earlier reject valid blocks due to a bug in 0.7 and earlier.

The reason the fork happened is because the 0.8 clients accepted blocks that the 0.7 clients rejected.

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

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

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

[Rarrikins]

Why would anyone want to be on a version that the miners are not using? ... you are opening yourself up to the possible risk of ending up on a useless fork.

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.

[Rarrikins]

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

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.

[Rarrikins]

The use of the same term for hashers and people who actually validate and prepare blocks for hashing has been causing confusion all over the place for a while now.

Maybe clearer terminology is called for?

-MarkM-

I put a proposal for that in a new thread.

[muyuu]

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

Did 0.7 generate blocks that 0.7 rejected?

[justusranvier]

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.

[taltamir]

The blocks being rejected by 0.7 are:
1. Possible to generate with 0.7 as well as 0.8
2. Perfectly valid blocks according to standard.
3. Being rejected because of a bug in 0.7

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.

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

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 a hindsight analysis of what you would have done differently had you been one of the programmers working on 0.8 and had known about this possible issue in advance.
The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit

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.

That was merely emergency measure to resolve the fork

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.

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

[solex]

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

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.

[antirack]

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

[muyuu]

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

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.

[antirack]

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?

[John Tobey]

@taltamir

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

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.

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

mixed environment of 0.7, 0.8 unmodified, 0.8 with option B

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?

The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit

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 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.

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

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.

[taltamir]

The programmers who made 0.8 didn't consider this forking scenario. This platitude is thus entirely without merit

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.

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.

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.

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