To mine bitcoin I believe that you take the input and add a salt number to that then run the hashing algorithm to find a suitable output, but how large can the salt be, couldn't I just take the current input subtract it from the previously found bitcoin input+salt to get a new salt, and use that new input plus new salt to find a suitable output (same output as the old bitcoin)?

2 Answers 2


It's actually called a "nonce".

It is a 32-bit number so is maxed at 2**32 or 4294967296.

If the hash and data given are valid, you can always hash the block header data to get the same block hash. If anything is changed, including the nonce, the hash will change, invalidating the block (header).

Each valid nonce is dependent upon the data being hashed and the target difficulty according to the protocol.

  • This is good information, but if the nonce can only range from 1 to 4 billion and an ASIC bitcoin miner can calculate 2 billion hashes per second, isn't it going to run out of nonce real quick? Jan 9, 2014 at 6:20
  • Okay, this helps: bitcoin.stackexchange.com/questions/13952/… Jan 9, 2014 at 6:25
  • @RogerPerkins If you run out of nonces, which start at 0, you can increment the timestamp.
    – user5107
    Jan 9, 2014 at 14:05

But how large can the salt be?

It is unsigned int (source, look for ScanHash_CryptoPP and nNonce variable there).

The range of the salt (nonsense) is: 0 to 2^32.

Couldn't I just [...] to get a new salt [...] to find a suitable output [...]?

No, you couldn't. The problem is that a cryptographic hash function, such as SHA256, must have statistically significant uniform distribution. Such distribution results in an avalanche effect. In simple words, if you change just a single bit in the input, each of the output bits will change with a 50% chance.

It means that you mathematically cannot tweak an input, to get a desired output. You cannot predict which salt will result in the correct output. Your only choice is to try-check. Have a look at the "manual mining" demoed in this answer.

  • So with input1 and input2 different, input1 + nonce1 = input2 + nonce2 will give different outputs? I thought the nonce was just a sequential number. Jan 8, 2014 at 23:38
  • Sorry, not sure I followed. SHA256(input1 + nonsense1) = AAA, SHA256(input2 + nonsense2) = BBB, SHA256(input1 + nonsense2) = CCC, SHA256(input2 + nonsense1) = DDD. And you cannot predict, in theory, what the output will be. That is by knowing any {input1, input2, nonsense1, nonsense2} you cannot say what will be the output {AAA, BBB, CCC, DDD}. You can only calculate. Or in other words, you can go input => output, but you cannot infer the opposite output => input.
    – oleksii
    Jan 9, 2014 at 10:38
  • When you say SHA256(input1 + nonsense1) = AAA, SHA256(input2 + nonsense2) = BBB, is that with input1 + nonsense1 <> input2 + nonsense2? What I'm asking is when input1 + nonce1 = input2 + nonce2, then is SHA256(input1 + nonce1) = SHA256(input2 + nonce2)? Jan 10, 2014 at 16:02
  • when input1 + nonce1 = input2 + nonce2, then is SHA256(input1 + nonce1) = SHA256(input2 + nonce2). That is correct, same input resolves to the exactly the same hash. However, there are no guarantees that SHA256(input2 + nonce2) produces the hash with n leading zeros. What am I missing?
    – oleksii
    Jan 10, 2014 at 16:18
  • if sha256(input1 + nonce1) is known to produce a hash with n leading zeros, then if nonce2 = input1 + nonce1 - input2 then input1 + nonce1 = input2 + nonce2 and sha256(input2 + nonce2) should also produce the same hash with n leading zeros, provided input2 is within 32 bits of input1. Jan 10, 2014 at 22:38

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.