Where in the Core code does the SIGHASH int get truncated to 1 byte before signing?
RE: bitcoin spinoff fork - how to make a clean fork without any replay attack and no blockchain visible changes
You are viewing a single comment's thread from:
bitcoin spinoff fork - how to make a clean fork without any replay attack and no blockchain visible changes
HASH(the modified tx with the 4 byte sighash int) -> 256 bits that is signed
then the SIGHASH byte (not int) is concatenated to the signature and that is what goes in the blockchain. it is explained in the http://bitcoinfactswiki.github.io/OP_CHECKSIG/
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Right that's what I meant sorry, 4 bytes are signed but only 1 byte goes into the serialized transaction for broadcast. So what I'm asking is, where in the Tx serialization process is the 4 bytes reduced to 1? Like literally where in the code or protocol spec?
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
the signature is generated, 70 to 72 bytes (maybe I am off by 1 here), and the sighash byte is just added to the end. It is in the protocol spec, so that is what I did and it works. not familiar with bitcoind code as I wrote iguanacore from scratch
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
Maybe it's this line right here, casting
nHashTypeas anunsigned char(1 byte):https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
yes, you found it. casting an int to char will truncate it
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit