[ANN] Slimcoin : Proof of Burn NEW BLOCK GEN, Mineable by low power computer!

[primer-]

Slimcoin is dead. Dead as a cat.

New CPU coin worth a look : https://bitcointalk.org/index.php?topic=822498.0

Dead ? Thank primer-, after you gone price rise from 180 sat to 10k sat. Diff rise from 0.03 to 0.3.
All thanks to you. Please feel free to leave forever, don't ever come back.

Good luck with the new clueless dev, idiot.

[AizenSou]

Slimcoin is dead. Dead as a cat.

New CPU coin worth a look : https://bitcointalk.org/index.php?topic=822498.0

Dead ? Thank primer-, after you gone price rise from 180 sat to 10k sat. Diff rise from 0.03 to 0.3.
All thanks to you. Please feel free to leave forever, don't ever come back.

Good luck with the new clueless dev, idiot.

Good luck with your self illusion, idiot.

[a123]

Slimcoin is dead. Dead as a cat.

New CPU coin worth a look : https://bitcointalk.org/index.php?topic=822498.0

Dead ? Thank primer-, after you gone price rise from 180 sat to 10k sat. Diff rise from 0.03 to 0.3.
All thanks to you. Please feel free to leave forever, don't ever come back.

Good luck with the new clueless dev, idiot.

Good luck with your self illusion, idiot.

Well he's not technically wrong xD



the new coin primer- mentioned is a prime based one, and those are really hard to accelerate.

I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.

[BitcoinFX]

...

the new coin primer- mentioned is a prime based one, and those are really hard to accelerate.

I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.

Gapcoin helps to find new Prime Gaps and is similar to Primecoin in many respects. Both projects are interesting and unique from a mathematical and scientific perspective.

I'm currently mining Gapcoin and Slimcoin (and sometimes some Primecoin too).

Slimcoin is mostly interesting from an economic perspective in terms of crypto innovation. The Slimcoin developer did a lot of really 'smart' things with this coin to make it different and it remains so.

If you look at Slimcoin's posts - he perhaps didn't really want this coin to have a pool and the choice of the unique dcrypt algo has certainly helped and somewhat hindered this coins progress in this regard. Other technical oversights have not helped with the situation or with Slimcoins adoption.

Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.

[a123]

Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.

Hmm I'm not quite for SHA-256 since I like the idea of SLM being a gpu/asic-resistant coin.

Oh, and NOMP server has finally accepted the first DCrypt block!

Code:

2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Submitted Block using submitblock successfully to daemon instance(s)
2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Block found: 00000002762cab5802109aa37cf8c5f08c77cde1611a017c3e3e130eea352695

[ArchitektoR]

Oh, and NOMP server has finally accepted the first DCrypt block!

Thanks a123, trying once again!

[hankrules]

Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.

Oh, and NOMP server has finally accepted the first DCrypt block!

Code:

2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Submitted Block using submitblock successfully to daemon instance(s)
2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Block found: 00000002762cab5802109aa37cf8c5f08c77cde1611a017c3e3e130eea352695

Excellent news and great work!

[Mr E]

Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.

Hmm I'm not quite for SHA-256 since I like the idea of SLM being a gpu/asic-resistant coin.

+1, I think the idea of using dcrypt is to discourage intensive mining, partly since the point of Slimcoin is to require less 'wasted' power in mining by encouraging proof-of-burn to be more significant than proof-of-work. I would favor an algorithm that's going to be hard to accelerate, for that reason.

(PS -- I downloaded the 0.3.2.1 Windows build from the Git releases, and it was crashing again like the old wallet did. I've had to go back to 0.3.2.0 for the time being. )

[BitcoinFX]

Lets put it to a vote to switch algo then - the logical choice being SHA-256 like Bitcoin and Peercoin. I think I would actually vote yes on that.

Oh, and NOMP server has finally accepted the first DCrypt block!

Code:

2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Submitted Block using submitblock successfully to daemon instance(s)
2014-10-27 19:55:45 [Pool]      [slimcoin] (Thread 1) Block found: 00000002762cab5802109aa37cf8c5f08c77cde1611a017c3e3e130eea352695

Excellent news and great work!

Dcrypt algo and CPU mining is OK with me! Someone will eventually find a way to mine it with a GPU or ASIC + CPU / RAM combo and cpu coin pools will always have problems from botnets obviously.

Anyway, herewith a single CPU instance at RunAbove - http://labs.runabove.com/power8/ - Not totally sure on the billing in comparison to other cloud server providers, but those are certainly some powerful core(s).



If you follow my set-up guide from this thread remember to use screen.

See: https://bitcointalk.org/index.php?topic=613213.msg9330074#msg9330074

Code:

screen

before you start mining using:

Code:

./minerd -a dcrypt -o stratum+tcp://www.slimcoin.club:41680 -u YOUR SLIMCOIN WALLET ADDRESS -p x --scantime 15 --retries -1 -t 1

You can then (press and hold) CTRL + A + D to get out of the screen session. Then type exit and press enter to close the terminal, although continue mining Slimcoin.

...

If you log back in to the terminal type: screen -r and Enter to check that your still mining Slimcoin.

If you need to stop mining Slimcoin type: sudo killall minerd and press enter.

To restart mining type / repeat only steps:

Code:

cd slimminer

Code:

screen

Code:

./minerd -a dcrypt -o stratum+tcp://www.slimcoin.club:41680 -u YOUR SLIMCOIN WALLET ADDRESS -p x --scantime 15 --retries -1 -t 1

[hankrules]

Dcrypt algo and CPU mining is OK with me! Someone will eventually find a way to mine it with a GPU or ASIC + CPU / RAM combo and cpu coin pools will always have problems from botnets obviously.

I have to agree here.  Switching to a different "CPU only" algorithm seems like a lateral move at best.

[a123]

(PS -- I downloaded the 0.3.2.1 Windows build from the Git releases, and it was crashing again like the old wallet did. I've had to go back to 0.3.2.0 for the time being. )

Any idea why? Dya have a debug log of what led to the crashes?

[a123]

Ok gotta go to bed, didn't manage to clean up the code yet. Will post up the updated submitblock code soon!

[oveeps]

Ok gotta go to bed, didn't manage to clean up the code yet. Will post up the updated submitblock code soon!

The lack of new function, lack of marketing, hope a123 go ahead!，I have always been optimistic about this coin！！

[a123]

I've posted up the fixed submitblock code, still with a quite a bit of debug commands that should output to your debug.log.

This should work nicely with NOMP code without much changes, just need to disable sha256 checks, as well as run a JSON RPC Batch proxy to split the batch commands into individual calls.

Native batch support will probably need to be fixed via a code-base upgrade.

First pool and first large pool bounties still open!

(If anyone noticed a short disconnect from the pool, apologies! I was testing the code to be committed)

[a123]

The lack of new function, lack of marketing, hope a123 go ahead!，I have always been optimistic about this coin！！

Yea think it has a lot of potential, hope we're all able to work together to raise awareness of the coin

[jonnylatte]

I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.

A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing

void digest_to_string(u8int *hash_digest, u8int *string)

in

https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.c

to

Code:

char * byte_to_hex =
        "000102030405060708090a0b0c0d0e0f"
        "101112131415161718191a1b1c1d1e1f"
        "202122232425262728292a2b2c2d2e2f"
        "303132333435363738393a3b3c3d3e3f"
        "404142434445464748494a4b4c4d4e4f"
        "505152535455565758595a5b5c5d5e5f"
        "606162636465666768696a6b6c6d6e6f"
        "707172737475767778797a7b7c7d7e7f"
        "808182838485868788898a8b8c8d8e8f"
        "909192939495969798999a9b9c9d9e9f"
        "a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
        "b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
        "c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
        "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
        "e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
        "f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";


void digest_to_string(u8int *hash_digest, u8int *str)
{
  register int si = 0;
  register int i = 0;
  for(; i < SHA256_DIGEST_LENGTH; i++)
  {
    memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
    si+=2;
  }
  str[SHA256_LEN] = 0;
  return;
}

Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.

I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.

I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.

[oveeps]

I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.

A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing

void digest_to_string(u8int *hash_digest, u8int *string)

in

https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.c

to

Code:

char * byte_to_hex =
        "000102030405060708090a0b0c0d0e0f"
        "101112131415161718191a1b1c1d1e1f"
        "202122232425262728292a2b2c2d2e2f"
        "303132333435363738393a3b3c3d3e3f"
        "404142434445464748494a4b4c4d4e4f"
        "505152535455565758595a5b5c5d5e5f"
        "606162636465666768696a6b6c6d6e6f"
        "707172737475767778797a7b7c7d7e7f"
        "808182838485868788898a8b8c8d8e8f"
        "909192939495969798999a9b9c9d9e9f"
        "a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
        "b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
        "c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
        "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
        "e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
        "f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";


void digest_to_string(u8int *hash_digest, u8int *str)
{
  register int si = 0;
  register int i = 0;
  for(; i < SHA256_DIGEST_LENGTH; i++)
  {
    memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
    si+=2;
  }
  str[SHA256_LEN] = 0;
  return;
}

Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.

I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.

I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.

The need for the development of new mining tool

[oveeps]

I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.

A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing

void digest_to_string(u8int *hash_digest, u8int *string)

in

https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.c

to

Code:

char * byte_to_hex =
        "000102030405060708090a0b0c0d0e0f"
        "101112131415161718191a1b1c1d1e1f"
        "202122232425262728292a2b2c2d2e2f"
        "303132333435363738393a3b3c3d3e3f"
        "404142434445464748494a4b4c4d4e4f"
        "505152535455565758595a5b5c5d5e5f"
        "606162636465666768696a6b6c6d6e6f"
        "707172737475767778797a7b7c7d7e7f"
        "808182838485868788898a8b8c8d8e8f"
        "909192939495969798999a9b9c9d9e9f"
        "a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
        "b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
        "c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
        "d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
        "e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
        "f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";


void digest_to_string(u8int *hash_digest, u8int *str)
{
  register int si = 0;
  register int i = 0;
  for(; i < SHA256_DIGEST_LENGTH; i++)
  {
    memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
    si+=2;
  }
  str[SHA256_LEN] = 0;
  return;
}

Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.

I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.

I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.

Need more gpu mining tool

[jonnylatte]

I just hashed all the block headers in the blockchain file (did not prune orphans because meh) and found the average "count" multiplier for the internal buffer size in lots of 1000 blocks. Here is the results:

Code:

 1000: 1035, 2000: 1014, 3000: 975, 4000: 955, 5000: 1022, 6000: 1082, 7000: 929, 8000: 947, 9000: 931, 
10000: 898, 11000: 845, 12000: 916, 13000: 1015, 14000: 1053, 15000: 1016, 16000: 1050, 17000: 976, 18000: 933, 19000: 969, 
20000: 937, 21000: 938, 22000: 868, 23000: 774, 24000: 781, 25000: 838, 26000: 699, 27000: 887, 28000: 909, 29000: 850, 
30000: 899, 31000: 845, 32000: 791, 33000: 730, 34000: 770, 35000: 685, 36000: 675, 37000: 707, 38000: 681, 39000: 648, 
40000: 570, 41000: 539, 42000: 530, 43000: 524, 44000: 449, 45000: 222, 46000: 297, 47000: 665, 48000: 434, 49000: 431, 
50000: 511, 51000: 587, 52000: 504, 53000: 346, 54000: 421, 55000: 505, 56000: 862, 57000: 878, 58000: 814, 59000: 496, 
60000: 278, 61000: 280, 62000: 311, 63000: 326, 64000: 240, 65000: 231, 66000: 263, 67000: 369, 68000: 336, 69000: 311, 
70000: 287, 71000: 274, 72000: 330, 73000: 346, 74000: 317, 75000: 338, 76000: 344, 77000: 385, 78000: 381, 79000: 344, 
80000: 374, 81000: 417, 82000: 424, 83000: 341, 84000: 368, 85000: 336, 86000: 384, 87000: 395, 88000: 385, 89000: 338, 
90000: 352, 91000: 404, 92000: 386, 93000: 368, 94000: 323, 95000: 369, 96000: 337, 97000: 381, 98000: 430, 99000: 331, 
100000: 372, 101000: 379, 102000: 369, 103000: 305, 104000: 339, 105000: 359, 106000: 305, 107000: 362, 108000: 311, 109000: 305, 
110000: 323, 111000: 327, 112000: 318, 113000: 290, 114000: 370, 115000: 302, 116000: 283, 117000: 329, 118000: 327, 119000: 361, 
120000: 345, 121000: 359, 122000: 344, 123000: 331, 124000: 349, 125000: 340, 126000: 291, 127000: 259, 128000: 295, 129000: 292, 
130000: 283, 131000: 272, 132000: 276, 133000: 253, 134000: 258, 135000: 292, 136000: 269, 137000: 270

Up to block 17000 the internal multiplier looks like what I what I got from sequential data (basically random hashes) but from there it steadily counts down.
I'm not sure if this is evidence of a GPU miner or someone who is optimized for low memory usage on a CPU or something else. But the most likely explanation is that someone or many people are mining hard with a software that is optimized completely in favor of processing power over memory usage. I would expect that even if there is a GPU miner the hashes from PoB blocks would make the internal hash more random though.

What is the ratio of PoB blocks to PoW blocks?

[jonnylatte]

Sample count values [seem to] confirm extreme optimization for processing over memory usage with occasional high values. So who is mining with their own software?

Code:

000000038e6a9957b844ea8060e4698ba266ff11a2dc70762b2f99b95999d76b
count 15
000000128aeb72d82db57a7cc74713fb932e951900de7a32a00884f34538b624
count 8
0000000ac812662e5f47f7069cd931f5c1e076f665e8a4ee783f75595fcbe6b6
count 32
0000000fecfa2c3e370b7035bd0bd8bf3c1160a9af41fdc954fa700e7a8d53d7
count 7
6eaa5b2bae0f8af242ee5fafa47406e444d47d93c9bbf7c8ee083079ffb03e20
count 72
00000000040cf7965c277f0f91202368744d1782fe9cbe1b7483988147f9e05c
count 5
47c06e5399e203b793814762ad008ba71f22cac4b04d6d3eb4a0ba00e7bf5257
count 1645
0b4ad69186e8f51816c4735460c335b544478108e4b62657b1fe4f1f8af59bcb
count 677
d9a60bbeac2a396a987d1ee8df71aae60a03e55b3e4e0d5d0a56300cfd5bc1d9
count 3337
82908d5862545b2944770d80ac6e268633eb300194d30e992f89739eee34ec0d
count 1659
00000005a749a6f731b06896c1f01aab9a4753e228ee78f69c7d06ae6bcf2d7c
count 6
000000060fa51f39a3ae21051b37720bb3972538eb95dea4610d5e2d11382c7c
count 7
00000010e9a669624e6528b5c4f2f4def09dca8364f860288ecb2a5f94f4347d
count 9
0000000a50c04bc270ad337143dd911308361d75091785a1b98bf35aa3eb8a16
count 11
0000000dbe67c7c55dbdc06bc13aff005a7e6d161a8f5c702509b02ccc06b6b3
count 6
df5495833a855960b641f5664a86643c53166661ed114925e1087c442efaea6e
count 807
000000009ee55c346b7606d95640dfcd43eddce27b65353783a0b614fba944e1
count 13
00000003fc72396f0993e1b91f329e19e8bd11b46ace9d0dba938173d5bcca6d
count 9
de20e1b3d9f85cd65fec37eeb332e38bf716b1e21f16f7ccec770edc8eeda71c
count 2133
0000000460bf0215bcea46a53e4be2dcf9841107a9ab20edae1b6c8b1b35f612
count 6
00000003d5432e8a53a12d9bebffbd6ee5f0d7379083d1efea657e11ddd5c2c1
count 6
00000004c75b3ff5139a4df7ed89b9d8c0c4c0710ec21f6e6bed06ded804f1ac
count 17
adefca97290494af097da26c4ffb08d0328480d9baf0bb744e6104fe669d66e8
count 163
000000009e33504d70da2b4b5af388290c5d59d5193b0f66331441f6e8079f1d
count 7
0000001118288b91973e93f7deea538799c7cbbe17438d937993add78921fce3
count 6
00000010c5e6aea9ee9d6c92c17792c026cfde067d7623f5f1345cd7499bb8f9
count 13
396249ae28d144959cf5c906cc4c54e4b2cf38fcdefbe8c23c5d26ac25d095e8
count 2915
0000000445068863752b7047b7bcfaa218778afa1192fb6988fcdc09fe064fd7
count 9
0000000ac52b23f39971e2b71f4f22ed903f87ec0dfe2ff34b8c543a6c4fbed2
count 32
324bc41a5458272d6196189d4e0ced3a3c91ef93cf7c3b68cd057d62b5cda068
count 632
0000000ebef69b1be03eef1e3a29d799a9c2128f84a45ae967b6bca922b4b563
count 11
c7c6de90b9dc4af55a4199100102cc4ef6f331814a5758f3d616a1507a716775
count 1885
0000000ab81cc123afd226ec6fc2fc213f02fa7b23a59769e5961b5af8121615
count 26
000000045001339273a41ec13435ebac288356cf1961c949f7b52c07bc987fca
count 8
8047ba3d706a39c0895905e5a3c1a456c1b656de2e5daddb40100c06d9fe424d
count 183
0000000d5afef5da78afe0016a0c35a22194b159b941a6457ddf862e924bfcd6
count 10
0000000f8b1f509c77ec38d1c0071e0cd13ddce4981002a1309d64ad8080971f
count 8
0000000ca3d9626968dd8ec767b979d310c81fa30eeaca9dd16d0d3983e7d4dc
count 25
8d2649268866a90c031e730ca51831c09e4648efa3f4d062e7a55a760acaeb9d
count 345
0000000643c0bd94913394a9ffd8e1ac98f79b7a6853bdfb7e8b18a879335a8e
count 11
2934ceb326a678f457d3a20a8142674c98794e54eaa2ce2984fffeff68fff977
count 4740
000000048fbcb7776d87aa58980e58824ba47542c396b8e7b65139f02be8d0a4
count 9
00000009223bb37341f9dde8d3e60155e18345b2c3eabf9104406c346446ce50
count 21
3f3a0f90c3d59ba183a9cc072e77501f392996f1b59f9df216c2bb4827234c63
count 387
000000007e36aab2351964c79301ec7c1135ba9e6cc9e2a9a41312987dcf9c70
count 8
000000059521b6f84e09c7022ad92c4a5454a917e83f5edcb6d509db72aa3215
count 7
00000002573db764e063e7cc1d81c281f2e76c4711d415a7662bb3be77aab1a5
count 21
b75680795414633d78f8fd3139ecb19de108c2ba1edefebe1cfd7572766229eb
count 183
00000006c7940055f75c84b6529d5aeb47a5f8645d2109bf4fb0272d80023bd5
count 10
f902f8137934436067948d44dc431540dd9a6e894446cb55a291b9f3cb76d81a
count 331
000000125ac03b677a2a16a250d66e3e51ffab85673a6017bf8b739df008f614
count 7
28955efff0c516acbc9af85a6903d5b1f6b34b0de7d83b7c243ecafdc84d1d0e
count 428
0000000614d9ddb8ee337dfc46092967bb5c781a71132d3178818f711b0ce7c4
count 11
0000000dee329cd6f7170a750da1c126a6a5daa1dd105ed8ba3a1b58d3b944eb
count 22
00000000f490215c5928584a6bcf820c04ae0ba731b3f416c8d35b8c3e77e0fe
count 13
12bd6668a2f0e6a1e56343e7af3a51c4d233e1f185816aa4eba886c300f8f2d6
count 210
0000000990d14ce9d38cc36fea610e2724425c347e7ca72729348141ced43c1b
count 8
00000007d850d5e0e0a96af5bac47cc5230f8cc4851c8b11d517eac55c2673eb
count 13
00000000e51275c1e604beb66a56da83d16cc77a31b255f1decdf4ed1e44cac5
count 27
f778b34e3d3a4a6473ee42fa6764938415f82d3f707ea0ad4f877a0f2b086f6b
count 602
6beab7df276e7612bdbc9577466694e247241f638f96061961454fffbf20c3c0
count 2475
0000000e86c08b4565de175fc1963f7ae2d3bc1ae67c03eb59fc13d1d0b90549
count 13
00000002c37383eae029efd49bee927e89e8e0b8577f593d9e5f908b02f4adce
count 6
0000000a6ac4e1a39734a199839bcbdc57407c455f0de499d4114434e899301a
count 6
00000004ea968db722b68d59093c4711198e578f28bc2e9491e6441e049f74f4
count 19
a0cbd163d83cd3243f4eefe9b6ee84a01ee614af72fb08bf31852f497eb41b04
count 543
000000119ebaae15f17bd94dc85f48391cb9133d281e2f511e5df157a6487f43
count 21
0000000279764e347b1b52ec3ee1bdb81bcfc53ba24cd20b6ce0b0db74fe9ddb
count 7
00000002941ad3fd55c9333133bd541e6de681bbf44044cfeb7bee2fba63abca
count 7
000000011fa7cd793541599011c199fdb74099c55ca96e3e7a194a364d1ab749
count 7
00000009ded7315547a282a01d6dfc94e7fdf650d93b1e5ac8ffe6348e279eba
count 8
8261ac08781a2e2387423c5f45d1739fa4d3504fac4548b7f089fcb4641b32d5
count 18
0e8986e725d02a8a0ec98dee57528109576bfc524e6cd5656978fc3ebcb85a9c
count 223
0000000a26d9504d999512367cf9d76cd3741571c6b0dd050cde190b5a384b3f
count 19
0000000830f97483c789681ca23bb04cc60e2045fb1ce412ff7ab6d7ba65e67b
count 13
0000000080240b55e8c7ec544e9f09392831c95350e898b3b5739c4307f12a28
count 7
000000054c4b048c23b2f4c3637e0afca687640443c734eaead0a8408488402a
count 9
b8303053a77f62d7580a775654c2468a266c5d21a1d4a170e2d917fb6faaa574
count 7
0000000dfa71f6302652aa807def51a5f5931486b16c5ae59b7b0e2b6e1be2d8
count 9
371273bb52588dee39fa2161976d06c9b5de3cc5a7b817f883bc2b2ff3c00a2b
count 2086
09edbf05b9a0c471549dc8b42f2a9ce61d0c5bd497e82f04ceed20db3e379924
count 791
0000000c4e6963ef6e2b585e78f544caabc1bf9e19b4d54c97ecfb266c6d1e9c
count 12
c9f472f32b9dd5158772556a60a41d1b0fc5beccb77f9cbb8fc996a33d590cad
count 476
be908605235d5137bdd4bcffc71acf971c4766b383732c3727ba2a23deb6fec0
count 3398
0000000fea63e7e334669130519052369e27debb4a954a51b8a637bc2f691ca3
count 19
00000012be129110eedef78d7a07643735b0f02be06160501f2a9a0fb19f52f3
count 18
000000056f22d66b38dd94a0406e0a814a83c7f7d22047f16b38a23a943e1ed4
count 32
a339291b62c15754d149f2300656b4deec69c3b01152e33f3cf24c4821ee0aff
count 2761
0000000c7e6529e5f81c369903db173c065448f000a80adbdad58dffce983b73
count 32
0000000c472938828c6b0238c3cb64ea0a18c8f94626f556d6d20b24f8c85671
count 8
347319680150db0544a38e4abf50ab7a039b3e82267a7c4eb89815622744f5b2
count 268
00000009f109ea6e95c9989ec38d122cc47818ca2ea5f247657233e9b762428e
count 27
0000000b8b1907f2e6491e6cf0f65696782dcccce5266b5d821156395e22c333
count 9
0000000a29c2f3526e92bc419c477252021f245571d9cea14f00801c2b597f23
count 9
ab0a14d9a24a884a228ed73e6433a3d79a5e226a203d26e1448d33b4a199b48f
count 250
00000007d78d1c092d6f9d606917985e0064928f5228297fd28fbbda2e73a9e9
count 7
36c37f4931b621e0d7081f3ccb08cab36e8122d56d1013b7b7a9e8c11f9369e8
count 4863
00000011c27ebd218e6bc269400f740b9fc48c269f53a7f38f552ddddb112b76
count 6
0000000f613c26eb5a1b4fdce5171790e9e351929c020ca5173380cf4276e2ec
count 8

EDIT: Just did the calculation on a few blocks I minted myself with PoB and found their count values to be in the range for random hashes, as expected.