OP_CHECKSIG signature hash type 0 On the Bitcoin Wiki's OP_CHECKSIG documentation:


  Firstly always this (the default) procedure is applied:
  
  
  the public key and the signature are popped from the stack, in that order. If the hash-type value is 0, then it is replaced by the last_byte of the signature. Then the last byte of the signature is always deleted.
  


The signature format is:


  0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]


In case if hash type is 0 then we should  get last byte from [S] 
and remove it I think it will corrupt signature!

Maybe I don't correctly understand this documentation. Could anybody explain the correct behavior in this case?
I've done some testing with pybitcointools and one of the BitcoinCore test vectors with a SIGHASH of zero.

For SIGHASH =0, the Tx which is signed 

It's just a matter of appending 4 nullbytes, instead of 01000000, to the signing transaction. 

The Core software checks for this non-standard hashtype now, however we can see there's no problem in validating these rare transactions since the code only checks for SIGHASH ACP, SINGLE &amp; NONE. See Python-Bitcoinlib's code for a Python interpretation

See this test vector, where the hash being validated is 11743b220e9e24e89abd4ff124a2740531fe7d7f9b4e26de14710a532fd543e2.

FWIW, Pybitcointools needs to have the txhash function edited so that instead of if hashcode:, it reads if hashcode is not None:. The else clause in that function was confusing me, but it appears to be for hashing signed transactions (ie to return the TxID)