Is the block nonce predictable in any way? It seems to be a proof of work on his own just like the block hash, but may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

2 Answers 2


When it's used as it's intended to, the nonce usually begins at a certain point and increments from there. This can restart every second, since there is a second-specific timestamp in the block, but modern ASICs can do far more than 2^32 hashes per second, so it seems reasonable that nonces should be distributed fairly evenly.

may a miner force a mined block to have a specific nonce? (if his hashrate allows him to)

Yes. He'd do this by fixing his block header's nonce and changing transactions instead (the coinbase transaction, a.k.a. block reward, is a perfect place for this); by changing any transaction, the Merkle root in the block header will change.

The usual mining loop only takes two SHA256 hashes per attempt. If you only include the coinbase transaction in your block, this will add (at least; I'm unsure if it'd have to fill out 1 to be an even number, as it does for 3) two SHA256 hashes per attempt, meaning you'd be (at least) twice as slow as normal. I'm also unsure whether existing ASICs are capable of doing this different calculation.

The number of hashes would grow with (proportional to the logarithm of) the number of transactions in the block. If you include just 2 more transactions (so I can mirror the example at the wiki). You'd have to do 3 double-hashes to rebuild the Merkle root (there are 7 double-hashes total, but some of them could be reused) before your double-hash of the block header, for a total of 8 SHA256 hashes (1/4th your normal speed).

  • What do you mean with "having his nonce entirely within the transactions"? I could mine a block containing a single transaction and a set of arbitrary nonces until I guess a valid hash containing one of them? Commented Aug 1, 2014 at 15:32
  • Normally, there are two nonces: the one in the block header, and an extraNonce in the coinbase transaction. If you choose to keep the nonce in the block header fixed, you need to change something (most likely the extraNonce) after every attempt.
    – Tim S.
    Commented Aug 1, 2014 at 15:44
  • I've updated my answer and comment to better address this.
    – Tim S.
    Commented Aug 1, 2014 at 15:47
  • Thanks Tim, very complete answer. Then I can assume nobody can predict or hash an arbitrary nonce. Commented Aug 2, 2014 at 9:29

No it is not predictable. If it was that would break how block discovery works.

To explain in very broad terms: a nonce is simply an incrementing number. It is combined with a random set of as yet unconfirmed transactions and passed through a simple hashing algorithm, which turns it into a long number called a hash.

It's this answer (the hash) that has to match the test : it needs to begin with a certain number of zeros for the block of transactions to have been considered "discovered", and hence confirmed.

If it does not match this test, the nonce is incremented by and the process begins again.

It is the fact that the number and content of the transactions combined with the nonce supplies the essential unpredictability of the process, meaning that ultimately nobody can say which miner will find the block.

As this is quite a heavy computing task (to continuously try new nonces and transactions until you find the block) the nonce also serves another purpose : to help other bitcoin nodes take a shortcut to check if the block you claim you discovered is correct. They simply need to take all the transactions in the block (you have to tell them which ones) and use the nonce to arrive at the correct Hash with the right number of zeros. This by contrast is a very light computing task.

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.