<p>I assume it is simply the result of lazyness.</p>

<p>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.</p>

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

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

CC BY-SA 3.0
2016-08-18T21:15:57.280Z
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
CC BY-SA 3.0
2016-08-19T00:28:09.503Z
Is it this line right here, casting `nHashType` as an `unsigned char` (1 byte):
https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32
pinhead
CC BY-SA 3.0
2016-08-19T08:29:11.697Z
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
CC BY-SA 3.0
2016-08-18T20:56:08.927Z
2016-08-18T20:56:08.927Z
Pieter Wuille
<p><a href="https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes" rel="noreferrer">This article</a> 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 <code>0x000000</code> 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?</p>

<signature><sighash-flags><checksig>
Why are SIGHASH flags signed as 4 bytes when only 1 byte is included in the transaction?
pinhead
# Why are SIGHASH flags signed as 4 bytes when only 1 byte is included in the transaction?

(Asked by: username_0 on 2016-08-18)

[This article](https://steemit.com/bitcoin/@jl777/bitcoin-spinoff-fork-how-to-make-a-clean-fork-without-any-replay-attack-and-no-blockchain-visible-changes) 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?

**Tags:** signature, sighash-flags, checksig


---

## 1 answers

### Answer by username_1 on 2016-08-18. Score: 5

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.

> **Comments:**
> **username_0**: 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?  
> **username_0**: Is it this line right here, casting `nHashType` as an `unsigned char` (1 byte): https://github.com/bitcoin/bitcoin/blob/d612837814020ae832499d18e6ee5eb919a87907/src/script/sign.cpp#L32  
> **username_1**: 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.  

---

