Implement BIP66 (0.8) #5765

No description provided.

utACK

Tested deployment using the same framework as I used in the other similar pulls (after first adding regtest support to the code) -- worked as expected.

I'm not sure whether this is even worth mentioning, but I noticed that there are a couple places in the code where we check that a signature produced by bitcoind passes verification (rpcrawtransaction.cpp:519 and script.cpp:1639), and to be completely consistent with the change to enforce DERSIG in the mempool, perhaps those calls to VerifyScript should be done with DERSIG as well? (Right now they're called with SCRIPT_VERIFY_P2SH | SCRIPT_VERIFY_STRICTENC.)

@sdaftuar Thanks for the tests, and nice catch, though it shouldn't matter. When combined with the standardness requirements, STRICTENC and DERSIG should be identical (they can differ when the result of a CHECKSIG is negated, but there are no standard scripts that do so).

Ok so given how this fork has gone horribly wrong - i.e. people advertised they would support BIP66, so the software switched over to the new rules only to discover that mining continues with the old rules - I propose that future hardforks include a FALL-BACK in the event that it is determined that not 95% is actually implementing the new rules. Is this possible to do for future hard-forks?

This was not a hard fork, and no, detecting that miners are not implementing the rules correctly is not possible in a consensus-safe way, as far as I know.

The solution to this is just educating miners that they risk all their income by doing so...

@sipa it would be possible I am sure, by analysing the InvalidBlocks that are coming though and checking if they would be valid in the case of a fall-back - if there are a sufficient number of these invalid blocks, then it would trigger the fall-back.