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?

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.

|improve this answer|||||
  • so when I submit a block to the network for the validation, the padding after the block header is not included? – Biology nerd Mar 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 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/… – Anonymous Mar 20 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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