I recently started to pay attention to what's going on at crypto-markets and, being developer for a long time, decided to take a look at the software we have out there in public access.

So I have a question to all crypto-guru here: As it seems from Bitcoin protocol specification, bitcoin will accept ANY nonce that satisfies target (block) bits condition. Every single miner I've seen made public is using sequential loop over nonce1 and nonce2. actual question: why do people implement +1 for the nonce in every thread, instead, let's say, having 2 thread one is going +1 from the beginning; second one is counting -1 from the end of nonces interval?

In my humble opinion, it would be faster if you're running several threads on the same interval...or, in the perfect world, split the entire interval in N subintervals leaving every thread do its own piece. From the mathematical point of view it seems like we gonna get higher probability of hitting 'golden nonce' using this approach, as opposed to +1 over the entire interval. Am I wrong here?

having all that said, I've downloaded the blockchain and ran couple of tests to see nonce distribution in uint32_t interval. results didn't surprise me...I've got pretty much uniform nonce distribution like: odd nonce: 49.997 even nonce: 50.003

split uint32_t into 1024 identical intervals and see how many nonces from existing blockchain are sitting in every interval. results are the same: uniform distribution.

again, why is it +1 in the miner loop? even though, (+3), (-2) would have yielded (in theory) better chances (faster) finding golden nonce vs others doing (+1).

  • 1
    Why would that be faster than giving every thread its own block header to mine? – Nick ODell Apr 10 '15 at 4:13
  • 1
    Which is quicker to guess a PIN?: randomly guessing or starting at 0000 all the way to 9999? – Wizard Of Ozzie Apr 10 '15 at 8:19
  • depends on your luck. but in theory, if you're using uniform random, you will most likely find a PIN faster. give it a try. simple software app will show it to you. Keeping in mind that you need to find new PINs over and over again, random gives you some advantages – Alex D Apr 10 '15 at 18:52
  • @NickODell, try it yourself: run cpuminer with 64 threads. thread speed will go down, but amount of accepted nonces will go up over limited amount of time. – Alex D Apr 10 '15 at 19:16
  • I think you're confused, thinking all miners are computing the same thing therefore doing +2 might give you headway. Every miner is running on a different random piece of work. The next point you need to know is that the PoW algorithm is progress free: every single number has the same chance, it doesn't matter if you start at the beginning or the end or middle. It doesn't matter whether you do +1 or +2 or +random. So everyone picks the simplest. – Jannes Apr 11 '15 at 17:48

The distribution of wining nonces is skewed toward 0 because this is a selection effect: most everyone starts searching for nonces starting at 0, so the lower nonces are found first, even though there may be also higher nonces that could produce a winning block: winning nonce values distribution

This illustrates very well that the distribution of nonces is uniform: histogram of valid nonces and hashes

source: https://en.bitcoin.it/wiki/Distribution_of_nonces_and_hashes

Thus, +1 in the miner loop is the simplest way of changing the nonce, and it works because the valid nonce distribution is uniform. ASICs often deal with nonces very differently. Also, ASICs can scan the entire nonce range very quickly, so it doesn't really matter where you start looking for a valid nonce.

  • Even in ASIC world, keeping in mind that they can scan the whole interval that fast, wouldn't it be faster to use random or another algorithm? – Alex D Apr 10 '15 at 19:13
  • 1
    @AlexD You can't get simpler than nonce++. ☺ Anything more than that (e.g., a pseudo-"random [number generator] or another algorithm") would just slow things down. People have explored SAT solving as an alternative to brute force bitcoin mining, but brute force is still faster. – Geremia Apr 11 '15 at 2:20
  • I didn't mention any random so far :) pseudo random is the way to nowhere in brutforce attacks :) but I'm pretty sure there's a better way of brut-forcing things in more efficient way! :) – Alex D Apr 12 '15 at 5:29
  • @AlexD If anyone discovers a better way, Bitcoin will have to adopt a different proof-of-work method. – Geremia Apr 13 '15 at 17:40

If you use four threads and split the range over the four threads, that means each thread finishes its range and starts a new one four times as often. That's clearly a losing proposition over giving each thread its own full range.

  • I wish I could do '-1' on you. your answer doesn't make any sense in terms my question. Please read it again. every thread is doing the same like: +1 at the bottom; next step would be -1 at the top. would that increase the entropy? – Alex D Apr 12 '15 at 5:23
  • @AlexD I don't understand what you're saying, I guess. Since every nonce has the same chance, all that matters is how many nonces per second you can try. What would the benefit to this complexity be? – David Schwartz Apr 12 '15 at 16:58

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.