In case you haven?t noticed, Bitcoin is going through some pretty intense tribulation right now, with tens of thousands of unconfirmed transactions, thanks to a “stress test” and, on top of that, forking issues due to invalid blocks being mined and propagated by large mining pools. What exactly is going on there? Let?s have someone else explain it for us:

Three months ago I discovered a miner with ~1% of the hashrate that was processing transactions with no signature validation at all. If I had sent that miner a transaction where I spent a million of other people?s bitcoins they would have mined it and the half of the non-verifying miners would likely have given it 6+ confirms for any SPV client; and thats the more fundamental issue here which no amount of version checking would help with.

Well that certainly doesn?t sound good. Maybe it should be fixed…?jstolfi weighs in:

The core devs tried to activate BIP66 through a very soft fork, so that clients would not even know that it was happening (otherwise they might get alarmed at the word “fork”). So they just let the new rule to be silently activated as soon as 95% of the miners signaled that they had upgraded to the new version of the software (v3). To make the transaction as smooth as possible, they allowed the players (clients, relay nodes, and miners) running both v2 and v3 to talk to each other even after the transition.

But that plan backfired because some v3 miners got a block B from one of the few remaining v2 miners and started to mine on top of it, not realizing that B was invalid under the v3 rules. For a while, that was the longer branch. That branch was perfectly valid for clients still running v2, and was assumed to be valid by some v3 wallet apps that did not do full checking of the blockchain. Meanwhile, other v3 miners, realizing that B was invalid, ignored that branch and started growing (more slowly) their own branch. The ‘bad? branch was already 6 blocks long when the core devs (who fortunately were watching the blockchain at the time) managed to warn those miners that they were mining an invalid branch. Those 6 blocks were then discarded, and the ‘good? branch soon overtook it. Fortunately there were no double-spends, and all transactions that were confirmed in the ‘bad? branch were eventually confirmed in the ‘good? branch too.

The same problem occurred again a few hours later, and this time the ‘bad? branch only got to 3 blocks before being abandoned. It is not known whether there were double spends this time.

To guard against possible repeats of the incident, possibly with double-spends, the devs had to issue a warning to all clients (even v3 ones, depending on the software they are using) to wait 30 confirmations (5 hours) for safety.

Thus, what was supposed to be a “stealth” fork became a major PR disaster.

IMHO, the devs blotched the fork. They should have programmed a delay of (say) 2 weeks between the “95% majority” event and the enabling of the BIP66 rules. Then they could have sent a waring to all v2 players, especially the remaining v2 miners and relay nodes, that they should upgrade before BIP66 went into effect. But that would have been bad PR… ha ha.

One thing is the ‘consensus rules? that say when a block is valid. Another thing is the algorithm that miners use when building the blocks that they try to mine. The ‘v3? label refers to the former only. By stamping ‘v3? on their mined blocks, they only indicated that they agreed to the version of the ‘consensus rules? that enforces BIP66 after the triger event.

The software that those miners were running would indeed have checked the BIP66 rule, if it got a chance to do so. But the software only checked the transactions to be included in the block that they were mining, and not those of the parent block that they got from another miner.

The v3 ‘consensus rules? say that a block is valid after the trigger event only if the transactions satisfy BIP66 (among other conditions) and the parent block is valid. But the v3 rules don?t say that miners have to fully check that the blocks that they issue are valid. It would be better for bitcoin if they did, but miners have the ‘right? to create their blocks any way they want, even post blocks full of random bits.

The miners should want to post valid blocks rather than invalid ones, because invalid blocks don?t pay anything; but they must win the race against other miners to earn anything. They figured out that they would earn more by gambling that the previous block was valid, and mining on top of its hash only, than by downloading it and verifying it first. If the previous block was v3-valid, their block would be v3-valid too. If the previous block turned out tobe invalid, well, bad luck.

The Bitcoin Core release that includes v3 does verify the parent block before mining on top of it; but miners are not required to run BitcoinCore, and the v3 ‘consensus rules? do not require anyone to run a particular version of the software.

An interesting detail is how the big pools steal the hash of the most recent block from other pools, even before it gets out to the relay nodes. That is why they couldnot even check its version stamp.

All they have to do is subscribe anonymously as members of the other pools, and they will get that information as soon as the pool manager receives a mined header from some other member. The pool?s interest is to make sure that the block just mined is valid, and to put all its members to mine on top of it as soon as possible, while it its still sending it out to the relay nodes.

To be precise, a miner gets bitcoins for being the first to mine the next valid block. They are not required to verify anything (and it is not possible to check whether they are indeed verifying anything.) They only verify enough to maximize their expected gain.

In particular, when they steal the hash of a recently mined block from some other pool, they are quite confident that it will be a valid block. So they don?t bother to check it, and that gives them a few precious seconds of advantage in the block race.

Usually that is a safe assumption; it failed in this case because of the switch-on of BIP66 and the “victim” of the theft rbeiong out of date.

Bitcoiners are blinded by greed? No way that?s possible!