Validiating Block Versions and Hash_Types

[roconnor]

It is my understanding that bitcoin does not verify the version number in block or transactions. If versions are meant as an extension mechanism, then presumably the client ought to enforce that all the version numbers are equal to 1 until such time as alternative block and transaction versions are added. Right now anyone can start spamming version numbers with any value they want I think.

Similarly the client only checks to see if the low bits of the HashType are SIGHASH_NONE or SIGHASH_SINGLE and all other combinations are treated as SIGHASH_ALL. Again, if this mechanism was intended to be extensible, then you need to check that the SIGHASH_ALL is correct and reject all other invalid HashTypes. Since there are only 5 bits available, spammers could easily exhaust all the HashTypes. Already at least transaction c99c49... is using an invalid HashType of 0 as if it were a SIGHASH_ALL.

[roconnor]

I've started putting blocks and transactions with random version numbers and random hash types into the testnet chain.

[gavinandresen]

Fixing this without inadvertently causing a blockchain split looks like:

1. "Discourage" transactions/blocks with weird hashTypes/versions.
2. Get 50+% of mining power to express support for a rule-change to declare other versions invalid by putting some string in their coinbase transactions.
3. Strictly enforcing the rule as of some block number or date after 50% of the network has upgraded (only for blocks/transactions after that date, old blocks/transactions that break the rule must be 'grandfathered').