4

This article brought to my attention that SIGHASH flags are 4 bytes long when signed, but only the last byte is actually included in the transaction. Then OP_CHECKSIG adds 3 bytes 0x000000 back on before verifying the signature. The article describes a clever way to introduce a fork using those three truncated bytes -- so why are the SIGHASH flags 4 bytes long in the first place? Is that a design flaw or feature?

Improve this question

1 Answer 1

Reset to default
4

I assume it is simply the result of lazyness.

In the original client source code (and still today), the sighash type is represented as an int. The serialization framework by default serializes ints as 4 little-endian bytes.

I assume Bitcoin's creator did not bother converting it to a single byte before serializing.

If there is any other reason, I'm afraid you'll need to ask him.

Improve this answer
3
  • Thanks Pieter that makes sense... but then when (in the code) is that int truncated to 1 byte? Is that just to reduce transaction size?
    – pinhead
    Aug 18, 2016 at 21:15
  • Is it this line right here, casting nHashType as an unsigned char (1 byte): github.com/bitcoin/bitcoin/blob/…
    – pinhead
    Aug 19, 2016 at 0:28
  • 2
    Yes, my assumption is that Bitcoin's creator cared about signature size (although he didn't realize that using DER encoding added 6 bytes for no reason), and used 1 byte for the sighash type there, but didn't care enough to do the same for the sighash calculation.
    – Pieter Wuille
    Aug 19, 2016 at 8:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.