the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce)
Mining Simulator (GitHub source) really helped me understand this. 
Topic: Why is the block header 80 bytes, not 128 bytes (= two SHA-256 blocks)? (Read 1057 times)
June 15, 2015, 07:21:24 PM
June 14, 2015, 01:19:54 PM
Neither is a block and neither is padded.
Sorry for the confusion, but "blocks" is ambiguous, hence my using qualifiers: "SHA-256 blocks" ≠ "Bitcoin blocks."See this post, which says "block header is 80 bytes, which is padded to 128 bytes, and split into two 64-byte parts."
The padding is only done internally by the SHA-256 algorithm, which works in 64 byte blocks. In every other aspect the block header is only 80 bytes: it is stored as 80 bytes, it is transferred as 80 bytes etc. Putting an extra nonce at the end of the block header would be a hard fork that would even affect SPV clients and the advantage would not merit the risk involved with a hard fork.
Note also that SHA-256 adds 9 bytes padding at the end so everything longer than 121 byte would require three blocks to hash.
June 13, 2015, 11:01:13 PM
Neither is a block and neither is padded.
Sorry for the confusion, but "blocks" is ambiguous, hence my using qualifiers: "SHA-256 blocks" ≠ "Bitcoin blocks."See this post, which says "block header is 80 bytes, which is padded to 128 bytes, and split into two 64-byte parts."
June 13, 2015, 09:49:13 PM
As I understand it, the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce), and the 2nd SHA block contains the rest, only 80-64 = 16 bytes. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? If so, why not make the nonce field, for example, 48 - 4 = 42 bytes larger (i.e., 52 bytes instead of 4 bytes)?
Neither is a block and neither is padded. The midstate is hashed and contains 64 bytes of the header. These 64 bytes are things that will not change for the current block that is being mined. The remaining 16 bytes of the header is the stuff that will change such as the nonce. I don't know the specifics, but the midstate and the remaining 16 bytes are combined and hashed to produce the full 80 byte header. Once this is done, the header and the data is sent back to the pool or node to broadcast. 
June 13, 2015, 07:50:42 PM
According to the Bitcoin Developer Reference, the block header is 80 bytes total:
As I understand it, the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce), and the 2nd SHA block contains the rest, only 80-64 = 16 bytes. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? If so, why not make the nonce field, for example, 48 - 4 = 42 bytes larger (i.e., 52 bytes instead of 4 bytes)?
That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?
(cf. the related Bitcoin StacxExchange question)
BYTES NAME
4 version
32 previous block header hash
32 merkle root hash
4 time
4 nonce
As I understand it, the midstate (1st SHA block) contains 64 bytes of the block header (which fields in particular I do not know, but I do know it doesn't contain the nonce), and the 2nd SHA block contains the rest, only 80-64 = 16 bytes. Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes? If so, why not make the nonce field, for example, 48 - 4 = 42 bytes larger (i.e., 52 bytes instead of 4 bytes)?
That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?
(cf. the related Bitcoin StacxExchange question)
Jump to: