# How large can the bitcoin salt value be?

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)?

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 '14 at 6:20
• Okay, this helps: bitcoin.stackexchange.com/questions/13952/… Jan 9 '14 at 6:25
• @RogerPerkins If you run out of nonces, which start at `0`, you can increment the timestamp.
– user5107
Jan 9 '14 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 '14 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`. Jan 9 '14 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 '14 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? Jan 10 '14 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 '14 at 22:38