Looking for nonces of even numbers

Question

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;

Answer 1

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

Answer 2

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.

Answer 3

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.