Sigh, it is a majority that are SPV mining ... do you even understand at all what that means?
A majority of the network is happy to risk mining on invalid data.
Even Greg, who coined the term "SPV mining", admitted that it was a bad name. There are three things that go by that name:
- (A) The miner starts to mine an empty block B(N+1) as soon as it gets hold of the hash of B(N), before it has got the full B(N); and publishes that empty B(N+1) if he solves it before getting the full B(N).
- (A2) The miner does (A) even when he notices that B(N) was itself empty, because the other miner was doing (A) too.
- (B) The miner does not bother to dowload and check the full B(N) at all, once it got its hash.
Miners will do (A) and (A2) if they can, because the alternative is to let their equipment sit idle or turned off in the interval between receiving the hash of B(N) and the full B(N). If that turns out to be bad for bitcoin, that is a flaw of the protocol; the miner is not to blame, because he was supposed to be greedy and do what is best for him.
(The protocol could be changed to prevent (A) and force the miners to wait for the full B(N); but then the useful hashpower would be less than the installed hashpower, so it is not clear that it would be better for the coin.)
Item (A) is not an entirely bad thing, because the empty B(N+1) will still help secure B(N) against tampering. The miner who mined B(N) *wants* to give its hash to all other miners, as quickly as possible, and *wants* them to do (A), because it helps secure his gain against orphaning. Every miner *wants* to get the hash of other miners' blocks as soon as possible, and do (A).
Item (A) is usually pretty safe for bitcoin, as well as for the miner of B(N+1), if he knows that the solver of B(N) is a known real pool: because that pool will lose lots of money and reputation if he sends a bogus hash out to its members. Choosing to do (A) is a calculated risk by the miner, with a clearly positive expected payoff. Last July (and in no other occasion that I know of) item (A) failed by
magnifying the mistake of BTCNuggets from 1 block to 6 blocks, thus causing monetary loss to F2Pool and AntPool
in addition to the loss suffered by BTCNugets.
Perhaps pools will modify their implementation of item (A) now that they know that the probability of other miners issuing invalid blocks is not negligible. In hindsight, the Fork of July could have been just one or two v2 orphans, rather than a 6-block chain, if the miners had refrained from doing (A) or just (A2), for a couple of weeks around the BIP66 switch-on event; that would have avoided the loss incurred by F2Pool and Antpool (but not the loss of BTCNuggets).
As for item (B), it should not be in the miner's interest to do that, so there should be no need to nag those who do it. But the expected loss from doing (B) is basically the transaction fees, so it is a weak deterrent. That is a fault of the protocol and of whoever set the minimum fee so low -- not of the miners.
However, I recall that F2Pool admitted to be doing (B) in July. They claimed that they had decided to do (B) after having one of their blocks orphaned. I do not quite understand that excuse; but, anyway, they promised to stop doing (B). But they also said that they would continue doing (A), for the reason above. You cannot blame them for that decision.
The SPV miners were already submitting v3 blocks before hand.
They knew about BIP66 coz they had already upgraded for it.
What they didn't do with their SPV mining was ... ... ... ... check the block version number since they didn't care to do that.
That involved more than they already did.
Failing to check the version number of B(N) was F2Pool's mistake, but that did not happen because they were doing (A). They easily could (and should) have checked the version when doing (A). They did not bother to check it because they did not foresee the risk of
other pools continuing to mine v2 blocks past the fork.
That check would not have prevented Antpool from extending the wrong branch, because they mined on top of a v3 block header.
... as for your 5% number, no that's wrong also.
It only means that in the previous 1000 blocks (~1week) there were 5% v2 blocks.
The actual number mining v2 blocks at the time of the change to v3 is lower than 5%
It's not a flat line of no more adoption for that entire week/1000 blocks ...
Maybe not 5%, but the percentage of v2 miners was high enough for a v2 block to be issued just after the fork.
Why is everybody blaming F2pool for mining an empty block on top of that one, and no one is blaming BTCNuggets (and the other miner who did the same 20 hours later) for having produced that block in the first place?
Wait, you are not saying that there was plenty of time for 100% of the nodes to be among the first 95% to upgrade, are you?