Bitcoin (and other crypto-coins) nonce loop

-1

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

Alex D

Posted 2015-04-10T03:44:56.013

Reputation: 103

1Why would that be faster than giving every thread its own block header to mine? – Nick ODell – 2015-04-10T04:13:39.800

1Which is quicker to guess a PIN?: randomly guessing or starting at 0000 all the way to 9999? – Wizard Of Ozzie – 2015-04-10T08:19:47.163

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 – 2015-04-10T18:52:02.110

@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 – 2015-04-10T19:16:05.353

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 – 2015-04-11T17:48:43.963

@Jannes, thanks for your input! that makes sense – Alex D – 2015-04-11T23:25:55.473

PoW is not an answer. it is giving you intervals. the pool, the task givers, they don't care if you can do it faster. if you can, they'll adjust your bits/diff... which is, in my opinion again, a red flag to the 'fuzzy-logic' high-speed approach, if I may say that :) – Alex D – 2015-04-12T05:14:24.270

sorry for the confusion, I meant 'green flag' for the fuzzy logic and red for the brutforce/rainbow kinda thing – Alex D – 2015-04-12T05:17:54.770

Answers

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.

Geremia

Posted 2015-04-10T03:44:56.013

Reputation: 3 665

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 – 2015-04-10T19:13:57.820

@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 – 2015-04-11T02:20:21.547

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 – 2015-04-12T05:29:28.640

@AlexD If anyone discovers a better way, Bitcoin will have to adopt a different proof-of-work method. – Geremia – 2015-04-13T17:40:43.053

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.

David Schwartz

Posted 2015-04-10T03:44:56.013

Reputation: 46 931

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 – 2015-04-12T05:23:03.320

@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 – 2015-04-12T16:58:14.943