<blockquote>
  <p>But how large can the salt be?</p>
</blockquote>

<p>It is <code>unsigned int</code> (<a href="https://github.com/bitcoin/bitcoin/blob/df840de5daef60a253e4d84d14ff72bb7188a6c0/src/miner.cpp" rel="nofollow noreferrer">source</a>, look for <code>ScanHash_CryptoPP</code> and <code>nNonce</code> variable there). </p>

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

<blockquote>
  <p>Couldn't I just [...] to get a new salt [...] to find a suitable output [...]?</p>
</blockquote>

<p>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 <a href="https://en.wikipedia.org/wiki/Avalanche_effect" rel="nofollow noreferrer">avalanche effect</a>. In simple words, if you change just a <em>single</em> bit in the input, <em>each</em> of the output bits will change with a 50% chance.</p>

<p>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 <a href="https://bitcoin.stackexchange.com/a/8033/11862">this answer</a>.</p>

CC BY-SA 3.0
2014-01-08T23:38:40.487Z
So with input1 and input2 different, input1 + nonce1 = input2 + nonce2 will give different outputs?  I thought the nonce was just a sequential number.
Roger Perkins
CC BY-SA 3.0
2014-01-09T10:38:45.967Z
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
CC BY-SA 3.0
2014-01-10T16:02:08.957Z
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)?
Roger Perkins
CC BY-SA 3.0
2014-01-10T16:18:01.037Z
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
CC BY-SA 3.0
2014-01-10T22:38:39.843Z
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.
Roger Perkins
CC BY-SA 3.0
2014-01-14T08:39:50.190Z
You can't subtract `input2` from `nonce1` any more than you can subtract two apples from two oranges. You can add two apples to two oranges, and then you can subtract two oranges. But you cannot subtract what you did not add. Because these numbers all have different bit patterns, you cannot mix and match them. "Foo" plus "Bar" equals "FooBar", but you "FooBar" minus "Qux" cannot be computed.
David Schwartz
CC BY-SA 4.0
2021-02-01T21:00:00.383Z
Okay, I think my confusion here was I was thinking input1 + nonce1 was some kind of binary addition, but it's really concatenation, maybe should be written like this: input1 || nonce1
Roger Perkins
CC BY-SA 3.0
2014-01-08T21:26:36.113Z
2014-01-08T21:26:36.113Z
2017-04-13T12:47:33.743Z
oleksii
<p>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)?</p>

<hash><salt>
How large can the bitcoin salt value be?
Roger Perkins
# How large can the bitcoin salt value be?

(Asked by: username_0 on 2014-01-08)

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

**Tags:** hash, salt


---

## 1 answers

### Answer by username_1 on 2014-01-08. Score: 0

> But how large can the salt be?

It is `unsigned int` ([source](https://github.com/bitcoin/bitcoin/blob/df840de5daef60a253e4d84d14ff72bb7188a6c0/src/miner.cpp), 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](https://en.wikipedia.org/wiki/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](https://bitcoin.stackexchange.com/a/8033/11862).

> **Comments:**
> **username_0**: So with input1 and input2 different, input1 + nonce1 = input2 + nonce2 will give different outputs?  I thought the nonce was just a sequential number.  
> **username_1**: 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`.  
> **username_0**: 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)?  
> **username_1**: 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?  
> **username_0**: 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.  
> **username_2**: You can't subtract `input2` from `nonce1` any more than you can subtract two apples from two oranges. You can add two apples to two oranges, and then you can subtract two oranges. But you cannot subtract what you did not add. Because these numbers all have different bit patterns, you cannot mix and match them. "Foo" plus "Bar" equals "FooBar", but you "FooBar" minus "Qux" cannot be computed.  
> **username_0**: Okay, I think my confusion here was I was thinking input1 + nonce1 was some kind of binary addition, but it's really concatenation, maybe should be written like this: input1 || nonce1  

---

