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

Murch
  • 75,206
  • 34
  • 186
  • 622
Alex D
  • 103
  • 2
  • 1
    Why would that be faster than giving every thread its own block header to mine? – Nick ODell Apr 10 '15 at 04: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 08: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
  • @Jannes, thanks for your input! that makes sense – Alex D Apr 11 '15 at 23:25
  • 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 Apr 12 '15 at 05:14
  • sorry for the confusion, I meant 'green flag' for the fuzzy logic and red for the brutforce/rainbow kinda thing – Alex D Apr 12 '15 at 05:17

2 Answers2

2

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
  • 51,554
  • 6
  • 106
  • 178
  • 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 05:23
  • 1
    @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
1

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
  • 4,626
  • 5
  • 38
  • 75
  • 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 02: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 05: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
  • I used to think that for a given block a valid nonce would eventually be found by +1 until success - is it actually the case that sometimes no nonce is found and the miner then has to abandon the block and try a different collection of transactions? – Prince M Mar 08 '21 at 06:58
  • @PrinceM Yes, that could occur. – Geremia Mar 08 '21 at 21:34
  • Why is the number of possible nonces finite? Why cant you just keep incrementing until one is found? Is this a "rule" or part of protocol? Or is it just faster? – Prince M Mar 09 '21 at 00:01
  • 1
    @PrinceM "Why is the number of possible nonces finite?" The nonce field in a Bitcoin block is a 32-bit (4-byte) number, so there are 2³² ≈ 4.3 billion possible numbers that it can represent. ASICs are so fast that they can scan the entire nonce range (do ~4.3 billion hashes) almost instantly. That's why extraNonce is useful for finding a "winning" block. – Geremia Mar 09 '21 at 16:57
  • @Geremia interesting, so there may be a nonce that makes that block work, it just doesn’t necessarily “fit” into the block. Got it! – Prince M Mar 09 '21 at 21:31