user15358: 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?

user9382: 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 & 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)

15358: <p>On the Bitcoin Wiki's <a href="https://en.bitcoin.it/w/index.php?title=OP_CHECKSIG&amp;oldid=57808" rel="nofollow">OP_CHECKSIG documentation</a>:</p>

<blockquote>
  <p>Firstly always this (the default) procedure is applied:</p>
  
  <ol>
  <li>the public key and the signature are popped from the stack, in that order. <strong>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.</strong></li>
  </ol>
</blockquote>

<p>The signature format is:</p>

<blockquote>
  <p>0x30 [total-length] 0x02 [R-length] [R] 0x02 [S-length] [S] [sighash]</p>
</blockquote>

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

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

<p>For <code>SIGHASH =0</code>, the <a href="https://github.com/vbuterin/pybitcointools/blob/master/bitcoin/transaction.py#L178" rel="nofollow">Tx which is signed </a></p>

<p>It's just a matter of appending 4 nullbytes, instead of <code>01000000</code>, to the signing transaction. </p>

<p>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. <a href="https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/script.py#L853-L902" rel="nofollow">See Python-Bitcoinlib's code for a Python interpretation</a></p>

<p>See <a href="https://github.com/simcity4242/pybitcointools/blob/master/tests/tx_valid.json#L20-L23" rel="nofollow">this test vector</a>, where the hash being validated is <code>11743b220e9e24e89abd4ff124a2740531fe7d7f9b4e26de14710a532fd543e2</code>.</p>

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