2

The bitcoin block header is 80 bytes, but the SHA-256 input is required to be a multiple of 64 bytes; as a result, the block header needs 48 bytes of additional padding.

Therefore, why doesn't the miner use the 48 bytes of padding as extra-nonce? Instead of changing the timestamp and Merkle root, why don't miners opt to change the padding instead?

1
3

Changing the padding would result in a completely different digest. Other validating clients do not have access to this "extra nonce" in the padding to validate it, and modifying their clients to implement it would be a hard-fork of the protocol.

The extra-nonce as implemented currently, placed inside the input of the coinbase transaction, was a backward-compatible change which utilized an unused area of the block to place random information. Existing validating clients would still validate the block as valid because the normal process of calculating the merkle root for the block was unchanged.

3
  • so when I submit a block to the network for the validation, the padding after the block header is not included? Mar 20 '20 at 10:01
  • 2
    Correct. The block header is serialized as 80 bytes, and the transactions immediately follow (prefixed by the transaction count as a CompactSize). The padding is internal to the SHA256 function. A bitcoin developer should not need to concern themselves with it unless they are writing an optimized SHA256.
    – Mark H
    Mar 20 '20 at 12:00
  • 1
    You seem to have confused history here a bit. extraNonce was part of even the first Bitcoin release. github.com/trottier/original-bitcoin/blob/master/src/…
    – Claris
    Mar 20 '20 at 12:31

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .