Looking for nonces of even numbers

Each one of bitcoin and its derived crypto-currencies has a nonce value in the block, no matter what the algorithm is. Every miner tries to search for a luck nonce which can make the hash value smaller than the target under the required difficulty.

However, recently I search scrypt based cryptocurrencies, like the dogecoin and vertcoin block chain for few blocks. I found most of the nonce are even numbers, except for (only manually browsed in block explorer)

Block #184161 - nonce = 8dce5c01

Block #184143 - nonce = 2a674001

Block #184139 - nonce = 930aa899

many other blocks from the latest block (Block #184174) and blocks in between of them are even numbers. Moreover, many nonce value are in hex number of form XXXXXX00 (in an integer hex number form, it is stored as 00XXXXXX in block), or multiples of 256.

The same outcome I observed in Vertcoin blocks. I manually traversed for few blocks and also found nonces of them are also even numbers.

I'd like to ask a question. If I configure the scrypt or n-scrypt to search only even numbers, is it possible to have higher chance to find the nonce which can solve the current quickly?

BTW, I won't expect the mining revenue of each miner in the pool (PPS or PPLNS) is going to be greater than that of normal nonce searching algorithm because the pool count for "shares" you found. When you skip odd numbers, you also lose the chance to get a share (solved by the odd nonce) which can meet the diff the pool gives to you. However, when a pool found a nonce that can solve the block, then the pool wins and gets the rewards.

Edited: Apr 18

I wrote a small program to collect some statistical data. From recent Dogecoin block #186,299 to #145,000 (the last mandatory update)

total 41,300 blocks

number of odds = 3,891 (9.42%)
number of evens = 37,409 (90.58%)
- ratio of odd to even is about 1:10
Among the evens, the number of multiples of 256 = 35,106
- 85% of total
- 93.866% of evens

Update: 4/20

I recently also checked the nonces from block 552,780 to 253,898 of Litecoin.

totally 298,883 blocks.

number of odds = 42,963 (14.374521%)
number of evens = 255,920 (85.625479%)
Among the evens, the number of multiples of 256 = 225,746
- 75.529890% of total

Update: 4/21

I use a small Perl script and call litecoind/dogecoind wallet to print out each block's nonce. It is very slow but quite simple. It would be very fast when you are using binary block database parser.

#!/usr/bin/perl -w

my $odd = 0;
my $even = 0;
my $m256 = 0;
my $total = 0;
for ($i = 186299; $i >= 145000; $i = $i-1) {
    $nonce = `dogecoind getblock \`dogecoind getblockhash $i\` | grep nonce`;
    chomp $nonce;
    $nonce =~ s/[^0-9]*//g;
    printf "%d %d\n", $i, $nonce;

    if (($nonce %2)== 1) {
            $odd++;
    }
    else {
            $even = $even + 1;
            $m256++ if (($nonce % 256) == 0);
    }
    $total ++;
}
printf "odds=%d (%f%%) evens=%d (%f%%) 256s=%d (%f%%)\n",
     $odd, (100.0*$odd/$total),
     $even, (100.0*$even/$total),
     $m256, 100.0*$m256/$total;

jclin

Posted 2014-04-16T18:25:41.287

Reputation: 450

2Every nonce has the same chance of solving a block or share. Using only even nonces will not change your odds at all. It could be that some mining software prefers to try even nonce values; perhaps it's more efficient on certain hardware or something. – Nate Eldredge – 2014-04-16T19:19:11.103

Yes, every odd or even number has the same probability to solve the block. However, the race game is that if your pool find a nonce solution earlier than other pool or others (solo), you win the round. Moreover, I don't think it is more efficient on certain hardware because only the nonce can be altered, the SHA and scrypt core algorithm could not be changed, every bit counts. – jclin – 2014-04-16T19:40:44.393

2I agree with @NateEldredge here. Also looking at an other scrypt based altcoin, Litcoin, I saw no significant difference between the occurrences of even and odd nonces. It seems to be related to Dodgecoin, not to the hashing algorithm in use. However, it would be interesting to know why the nonce values take this shape in Dodgecoin. Dodgecoin. – Jori – 2014-04-17T14:56:01.233

2I get similar statistical data among LTC and DOGE, (even Vertcoin). Don't known the reason but looks very interesting. – jclin – 2014-04-21T06:24:33.423

It would probably be pretty easy to perform a controlled test at low difficulty. If even nonces really are significantly more successful it would suggest a weakness in scrypt. – Nate Eldredge – 2014-04-21T13:35:53.353

Would you be willing to share the code that gathered your data? – Nate Eldredge – 2014-04-21T23:37:23.953

1@NateEldredge, please see my latest update. Just a small perl to retrieve block nonces. – jclin – 2014-04-22T01:56:12.323

1At this point, I believe your seemingly innocent question deserves an full-blown investigation, publishing its partial results in a blog, or even (should you polish them) in a journal. If the disparity holds true for other scrypt-based coins, you might have spotted a vulnerability or a nice way to increase profitability of miners! As Nate suggested, might be worth testing in an isolated, small network. Have you checked for SHA-256 based coins? Where can I tip you for your efforts? – Joe Pineda – 2014-04-23T03:31:02.700

Thanks for your suggestion, @JoePineda. Yes, I'm also conducting a small experiment. I didn't checked for SHA-256 based coins because I quickly browsed through few blocks of bitcoin and didn't see any regular patterns. When I checked Dogecoin block-chain, I noticed that even numbers appears more often, and in a block explorer, it shows the nonce in hex number so I noticed that so many nonces are multiplies of 256. And you can see my profile for the details. Thanks! – jclin – 2014-04-23T05:23:16.907

There is one variable that you are not considering however, if I was mining I would be right on this. The variable is the transactions that are included in the block, which is always random. – T9b – 2014-04-23T23:36:24.730

That's why I should test this on public p2p network, not a small and closed test-net. Moreover, the nonces found in the article are retrieved from existing public scrypt-based cryptocoins, no matter the number of transactions in each block is only few numbers or few dozens of transactions. – jclin – 2014-04-24T02:40:51.800

1Note that depending on endianness, "multiples of 256" == "small enough that I only bothered to fill in 3 bytes, not all 4" – Tim S. – 2014-04-24T20:36:34.890

I see your point. The getwork protocol provides data in little endian. Check LTC block 100000 , http://goo.gl/w0UWpx, and https://litecoin.info/Block_hashing_algorithm, the decimal number 2147586629, or 0x80019245 in hex, and is stored as 0x45,0x92,0x01,0x80 in little endian in block. The nonce you see either in the blockchain web or wallet (getblock method) are converted to host endian to show the 32-bit number (x86 is also little endian, so no convert need). That means all multiples of 256, which is in the form of XXXXXX00 in hex, are stored as "00XXXXXX" in the block.

– jclin – 2014-04-24T21:11:18.260

Answers

I think that Tim S. may have the answer with his comment about endian-ness.

Your observations about the nonce having its lowest byte zero (being a multiple of 256), are with respect to the little-endian byte order of the block itself. From the perspective of a big-endian machine, these are statements about the high byte of the nonce.

So consider a miner which is big-endian. The natural algorithm is "start with nonce=0, compute scrypt, increment nonce, repeat", so your "even" nonces will be tried first. However, when a new transaction (or a new block from another miner) arrives, a new block header has to be constructed, and it would be natural to restart the nonce at zero when this happens. In order to get a nonce that is "not a multiple of 256", it has to complete 2^24 hashes before being restarted.

Of course, x86 is the most common desktop CPU, and it is little-endian, but most scrypt mining is done on GPUs. I hypothesize that a majority of these GPUs are big-endian, or at least that some common mining software causes them to increment their nonce in a big-endian manner. Does anyone know if this is the case?

From this chart, it looks like modern GPUs can run scrypt at roughly 1 Mhash/sec. So 2^24 hashes would take 16 seconds. Litecoin is currently averaging roughly 10K transactions per day, which is an average of one every 8 seconds or so. So it would not be surprising that a miner would usually not get into their high byte (which for you is the low byte) before restarting.

This hypothesis would also explain why we do not see such a pattern with Bitcoin. Current SHA-256 ASIC miners run at many Ghash/sec, and so are very likely to go through all 2^32 possible nonces before being restarted by new transaction data. (We might see patterns in the extraNonce, though.)

Nate Eldredge

Posted 2014-04-16T18:25:41.287

Reputation: 21 420

1Not quietly, only AMD GPU is big endian. The hash still has to be calculated in little endian order. Even hardware can compute the hash without caring endian-ness to obtain a hash value, however, the nonce will be re-check with cgminer scrypt (in CPU) again before send to the pool. If GPU uses big endian to compute the hash and gets a valid result, then cgminer will reject that. So the nonce value must be consistent read by either big or little endian platform. You can use AMD's extension with printf to print the nonce in GPU and the cgminer's nonce to see they are the same value. – jclin – 2014-04-25T01:08:53.777

The remain 2^8 is zero is also not possible for so many cases. For 2^24 it only needs 16 seconds to compute in 1MH/s GPU, so it will advance to the next byte of 2^8. When any bit of highest 8 bits of big endian is not zero, it could not be multiples of 256 in little endian. Considering the block time of LTC is 2.5 minutes, and Dogecoin is target for 1 minutes, it is long enough for GPU to use the remain 2^8 bits. When it exhaustively searched 2^32 and found nothing, the miner increases the timestamp 1 second and starts over and over again. – jclin – 2014-04-25T01:16:55.573

You can check the source code of GPU OpenCL scrypt in popular cgminer/sgminer. The OpenCL miner counts the nonce from 0 to an upper value by using thread id as the nonce. So basically it is a incremental value, for example, 4096 threads are issued to compute nonce from 0~4095 (because threads numbered from 0 to 4095), and then 4096~8191 in the second run, and so on. You can add extra printf or applog to cgminer/sgminer to see what the nonce can solve the diff and accepted by the pool. Basically the nonce printed for every accepted diff is also a increment value from small to larger number. – jclin – 2014-04-25T01:48:49.203

@jclin: Thanks for the comments. I realized the mistake about the low bit shortly after posting but did not get to correct it until now. I appreciate the details about cgminer and its interaction with the GPU; I will read them more carefully when I have more time. – Nate Eldredge – 2014-04-25T02:01:37.440

I also need to correct my comments. "2^8 bits" is the high byte (or 8 bits and has 2^8 values) – jclin – 2014-04-25T03:18:39.393

An interesting experiment has occurred to me after reading your answer: conduct the same text on Bitcoin and other SHA-256 coins' blockchain from before the introduction of ASICs, and then again from before everybody jumped into mining with CPUs - the results might have a different distribution, or they might not. Both results would be really interesting! – Joe Pineda – 2014-04-25T12:29:41.513

I agree. The endianness can provide a clue that shows different mining equipments (GPU or ASIC) found the block. – jclin – 2014-04-30T05:50:04.030

I conducted the following tests using C# (using the block header from the Litecoin wiki; Dogecoin is the same deal). Here's a test using scrypt: (I didn't preset the limit at 14857; it just took so long I stopped it there)

var dict = new Dictionary<uint, int> { { 0, 0 }, { 1, 0 } };
byte[] blockHeader = new byte[] { 0x01, 0x00, 0x00, 0x00, 0xae, 0x17, 0x89, 0x34, 0x85, 0x1b, 0xfa, 0x0e, 0x83, 0xcc, 0xb6, 0xa3, 0xfc, 0x4b, 0xfd, 0xdf, 0xf3, 0x64, 0x1e, 0x10, 0x4b, 0x6c, 0x46, 0x80, 0xc3, 0x15, 0x09, 0x07, 0x4e, 0x69, 0x9b, 0xe2, 0xbd, 0x67, 0x2d, 0x8d, 0x21, 0x99, 0xef, 0x37, 0xa5, 0x96, 0x78, 0xf9, 0x24, 0x43, 0x08, 0x3e, 0x3b, 0x85, 0xed, 0xef, 0x8b, 0x45, 0xc7, 0x17, 0x59, 0x37, 0x1f, 0x82, 0x3b, 0xab, 0x59, 0xa9, 0x71, 0x26, 0x61, 0x4f, 0x44, 0xd5, 0x00, 0x1d, 0x45, 0x92, 0x01, 0x80, };
for (uint nonce = 0; nonce < 14857; nonce++)
{
    var nonceBytes = BitConverter.GetBytes(nonce);
    Array.Copy(nonceBytes, 0, blockHeader, blockHeader.Length - 4, 4);
    var hash = SCrypt.ComputeDerivedKey(blockHeader, blockHeader, 1024, 1, 1, null, 32);
    if (hash[31] == 0)
        dict[nonce % 2] += 1;
}

Results:

0 32
1 29

And with SHA256 (using the block header from the Bitcoin wiki)

var sha = SHA256.Create();
var dict = new Dictionary<uint, int> { { 0, 0 }, { 1, 0 } };
byte[] blockHeader = new byte[] {0x01,0x00,0x00,0x00,
    0x81,0xcd,0x02,0xab,0x7e,0x56,0x9e,0x8b,0xcd,0x93,0x17,0xe2,0xfe,0x99,0xf2,0xde,0x44,0xd4,0x9a,0xb2,0xb8,0x85,0x1b,0xa4,0xa3,0x08,0x00,0x00,0x00,0x00,0x00,0x00,
    0xe3,0x20,0xb6,0xc2,0xff,0xfc,0x8d,0x75,0x04,0x23,0xdb,0x8b,0x1e,0xb9,0x42,0xae,0x71,0x0e,0x95,0x1e,0xd7,0x97,0xf7,0xaf,0xfc,0x88,0x92,0xb0,0xf1,0xfc,0x12,0x2b,
    0xc7,0xf5,0xd7,0x4d,
    0xf2,0xb9,0x44,0x1a,
    0x42,0xa1,0x46,0x95,};
for (uint nonce = 0; nonce < 1000000; nonce++)
{
    var nonceBytes = BitConverter.GetBytes(nonce);
    Array.Copy(nonceBytes, 0, blockHeader, blockHeader.Length - 4, 4);
    var hash = sha.ComputeHash(sha.ComputeHash(blockHeader));
    if (hash[0] == 1)
        dict[nonce % 2] += 1;
}

The results:

0 1908 
1 1951

This shows that, regardless of whether the nonce is even, coin algorithms produces roughly the same number of high-difficulty results. (I believe this is a good test of both SHA256 coins like Bitcoin and scrypt coins like Litecoin and Dogecoin; yes, I'm pretending the difficulty is much lower by only paying attention to one byte, but the point remains)

So why are multiples of 256 and even numbers so common in the real world? My guess is that mining software most commonly chooses these nonces, though there's no benefit to it. For example, what you call a nonce divisible by 256 could be considered a number under 2^24 (with reversed endianness). Nonces don't need to be chosen with high entropy, so it's acceptable for them to be somewhat predictable - just as long as you're not wasting your time by using the same nonce twice on the same block header.

Tim S.

Posted 2014-04-16T18:25:41.287

Reputation: 4 159

Please note that I got the results from scrypt based crypto-currencies. I also did not see the same pattern mentioned in my question found in SHA256 based algorithm. Moreover, running the algorithm only is not accurate, because there is a target value, which can be derived from the difficulty, and the sha256 or scrypt result has to be less than the target. If you are also running scrypt algorithm only, I guess you the same results that odds and evens have no great difference on their occurrences. – jclin – 2014-04-24T20:28:27.587

I'll see if I can do a proper test with scrypt. – Tim S. – 2014-04-24T20:33:55.420

@jclin I've updated my answer to include scrypt. As I expected, even nonces are no better than odd ones. (I'd be highly surprised if they were - it would mean these crypto hashes could actually be easily manipulated) You've found an interesting triviality, nothing significant. – Tim S. – 2014-04-24T20:55:10.530

I understand that data (even nonce is the LSB=0) computed with sha256 or scrypt won't produce any significant results of favoring even nonces. When LTC in low difficulty, for example block 0~10, your can see most of then are odd numbers. The nonce found in the block might not be the only solution, but just the first one found to be less than the required target value. So for example, LTC block #5 nonce is 6103, and there should be a even number greater than 6103 can solve the block under the difficulty. Your program just prove that many nonces can match your requirement of hash[0]=1. – jclin – 2014-04-24T21:46:39.640

So I asked the question because I don't understand that found in blockchain. I do assume evens and odds should be evenly found in the blockchain because all miners search nonce from 0~2^32. No one will skip odd number because the in pooled minig, if someone skips the odds, he won't get the share which can solve the diff provide by pool. If someone just calculate the nonce on 2^24 space, he might need to alter some data, such as time stamp, to calculate the next nonce from 0 to 2^24. So the last byte with 2^24 forms a 4-byte integer. It does not make sense to ignore 8 bits of the nonce. – jclin – 2014-04-24T21:57:39.870

See my comment replied below the original question for the endianness issue. Hopefully I did not spend much time on the interesting triviality. I think the most time spent are replying comments, writing small perl script (smaller than comments I replied in words), and crypto currencies and miner software are open source. – jclin – 2014-04-24T22:33:45.410

2@jclin: If scrypt really is secure, skipping nonces or not is irrelevant in either solo or pooled mining. Every nonce is equally likely to produce a valid block, and likewise, every nonce is equally likely to produce a valid share (which is just a lower difficulty target). You could run through all numbers in order, or the even numbers, or the primes - it makes no difference. – Nate Eldredge – 2014-04-25T00:27:09.837

The endianness might be not an issue because either in big or little endian, it allows a way to increase the possibility to find the nonce quickly compare to others who just sequentially iterate over 2^32 times.

In big endian, the result means > 80% nonces are found under the space from 0 to 2^24, so don't waste time to continue to try 2^24 to 2^32, just advance to next second or alter some data to start finding the nonce from 0 again.

~~In little endian, the result means > 80% nonces are multiples of 256, so you might also have 80% ~ 90% possibilities to find the nonce that can solve the block.~~

Because the nonce is not predicable, either counting the nonce from 0 up in big endian or little endian should not be a issue. They always could find a possible solution to the block.

jclin

Posted 2014-04-16T18:25:41.287

Reputation: 450

2No, I think you have got a misconception. This approach will not find a winning nonce more quickly - it will be exactly the same. Every nonce has an equal chance of winning. The value of the winning nonce, if there even is one for a given block, is completely random; it is just as likely to be between 0 and 2^24 as in any other equal sized range. For some blocks (indeed, the vast majority), there is no 32-bit nonce that wins. For others there might be many. – Nate Eldredge – 2014-04-25T14:46:44.840

So it doesn't matter at all which nonce values you try, or whether you try all nonces for a given block, or whether you give up before trying them all and change the block header in some other way. At the end of the day, the average number of winning blocks you have found is related only to the number of different valid block headers you have tried to hash - exactly how they differ is totally irrelevant. – Nate Eldredge – 2014-04-25T14:48:21.393

And according to my hypothesis, the reason more people are finding nonces between 0 and 2^24 is because more people are looking there - because it happens to be computationally convenient to do so. If we all switched to a miner that preferred to try nonces between 145235236 and 162012452, we'd expect to find lots of winning nonces in that range, but the total number found would be exactly the same, on average. – Nate Eldredge – 2014-04-25T14:51:37.423

I believe every nonce has an equal chance of winning. Considering the searching game is sequential, what nonce you first have or quickly get is the key to get the block solved. Like a dice game, if you know number six shows up frequently, so you could buy six to win more than others. Rolling a dice multiple times and shows 6,6,6,6 does not mean the dice is unfair. It could be followed by 5,5,5,5,4,4,4,4,...,1,1,1,1 and the possibility of every number of the dice is 1/6, and we could be at the 2nd or 3rd appearance of 6. – jclin – 2014-04-25T15:08:05.580

I'm not sure it is computationally convenient or not to compute only 24 bits of an integer. As I know, except for ASIC miner implementation, the popular cgminer and sgminer scans nonce till 0xFFFFFFFF or time's up or abort due to new block. – jclin – 2014-04-25T15:17:13.793

Quite right. What I conjecture is that it usually does abort before getting to 0x00FFFFFF. Note that a new block is not the only thing that would trigger a restart - so would the arrival of a new transaction that the miner decides to include in the current block (which changes the Merkle root value in the header). A new transaction arrives every few seconds on average - much more often than a new block, which takes an average of 2.5 minutes. – Nate Eldredge – 2014-04-25T17:51:33.360

The "computationally convenient" part is that it's convenient to start with a nonce of 0 after each restart - and this means that low nonces are tried much more than higher ones. It would not really be any less convenient to start at a nonce of 0xDEADBEEF instead, it would just look weird in the code - but if they did, this question would be about why so many nonces have 0xDE as the low byte. – Nate Eldredge – 2014-04-25T17:56:20.567

@NateEldredge Don't forget the timestamp, which should be updated every second (don't know for sure if they actually do that, but this would trigger a nonce restart much faster than a new incoming transaction). – Jori – 2014-04-27T09:40:10.047

Restarting on every second is a miner choice, not a mandatory requirement for the mining I think. But there should be a tolerant for the stale seconds, not all outdated timestamps are accepted. The new incoming transactions (within few seconds) are not also required to the recent block specially when the fee is zero. – jclin – 2014-04-28T06:06:52.273