4

According to the Bitcoin Developer Reference, the block header is 80 bytes total:

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?

Improve this question
7
  • What you are suggesting has been proposed on bitcointalk (can't seem to find the link). I think the problem with this is that it would cause a slight resign of ASICS, be a hard fork, and updating the extranonce once every 2^32 hashes is extremely negligible anyway.
    – morsecoder
    Commented Jun 14, 2015 at 3:38
  • @StephenM347 Hashing will have to get fast enough that recomputing the Merkle root for a change in extranonce would be a bottleneck, so why not just put extranonce straight in the midstate SHA block in the first place, for example?
    – Geremia
    Commented Jun 14, 2015 at 3:46
  • 2
    Recalculating the merkle root will never be the bottle neck. Crunch the numbers, I've done it before. Bear in mind that recalculating the merkle root takes Log(N) hashes (N = # of transactions in the block), not N. Even if one CPU couldn't generate enough work for an ASIC farm, you'd just have to get a processor with more cores. You have to recalculate the merkle root periodically for new transactions anyway.
    – morsecoder
    Commented Jun 14, 2015 at 3:56
  • @StephenM347 Why is extranonce updated every 2³² hashes?
    – Geremia
    Commented Oct 23, 2015 at 6:25
  • the nonce is a 32 bit integer, so there are 2^32 values you can try before you run out and need to change something else.
    – morsecoder
    Commented Oct 23, 2015 at 10:56

1 Answer 1

Reset to default
5

It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much.

Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes?

Yes, (source) but your reasoning is flawed. Even if the nonce space were so large that it extended into another block, that would just mean that midstate would represent the state after hashing all but the last block (block in the cryptography sense, not the Bitcoin sense.)

Also, if the block header were exactly 128 bytes, the padding would extend it to a third block. You only have 119 bytes before that happens.

That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?

Not really. You can check 2^32 hashes before incrementing extranonce, after which you only need to do ten or so hashes before you get back to mining.

Generally, in modern ASICs, even that part has been offloaded. There will be some sort of small processor within the ASIC, like an ARM core, which takes a block template as input and outputs block headers for the SHA256 cores to work on.

So the cost isn't one of speed, but complexity.

Like many things in Bitcoin, I think this is a technical decision that made sense at the time, but aged poorly.

Improve this answer
5
  • The size of the block headers is going to matter more when we decrease the time between blocks.
    – Meni Rosenfeld
    Commented Jun 14, 2015 at 8:53
  • @MeniRosenfeld Does it? I mean, we're talking about an extra 4-8 bytes per 80 bytes. That doesn't seem like a significant difference.
    – Nick ODell
    Commented Jun 15, 2015 at 4:01
  • Right, if it's just a small change it won't matter much. But if you were to, say, double the header size, you'd double the resource requirement for SPV clients, which can be significant when you have GHOST-accelerated blocks and SPV on cellphones or even smaller devices. Though, probabilistic verification schemes might resolve that.
    – Meni Rosenfeld
    Commented Jun 15, 2015 at 14:22
  • @MeniRosenfeld, you think the target block time will be changed? Given how hard it is to get everyone to agree to change a simple maximum block size parameter, I'm skeptical. Unless it is done by everyone moving over to a sidechain or something.
    – morsecoder
    Commented Jun 15, 2015 at 15:24
  • @StephenM347: I certainly hope so. It's just one of many things that will need to be sorted out eventually.
    – Meni Rosenfeld
    Commented Jun 15, 2015 at 18:46

Your Answer

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

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