Mining is getting too difficult now is there any way to work out how many miners are on the network?
Trade secret. But I am near the output of an Antminer s1. Grin.
I'd be surprised, an AntMiner S1 is 180 GH/s, and based on the network's current difficulty, it's hash rate is somewhere below 230 MH/s
Math for anyone interested: current difficulty is 23A79E4A
For ballparking this, we only care about the first two digits (23). Let's add 1 to it, so that we overestimate instead of underestimate: 24.
24 is, in hex, the number of zeroes that need to be at the beginning of a winning hash. In decimal, that's 36.
Therefore, you need 36 zeroes at the beginning of a hash for it to win. Only 1/(2^36) hashes will, on average, meet this requirement. That means, on average, the network produces 2^36 hashes every time a block is produced (5 minutes). As such, it does (2^36)/300 = 229,064,923 hashes per second, or (229,064,923/(1024 * 1024)) = 218.45-ish MH/s.
Thanks for making the calculation. can ASICs be used with Pascal, theoretically? is the algorithm double SHA256?
Short answer: the current Bitcoin-style SHA256D ASICs *probably* wouldn't work.
Here's why:
The algorithm is double-SHA256, but that doesn't necessarily mean current ASICs are capable of doing it, because it isn't the same exact "flavor" of SHA256D. Bitcoin and other SHA256D cryptocurrencies for which ASICs are designed have an 80-byte header which is hashed, consisting of 6 fields (version, previous block hash, merkle root hash of current block, timestamp, nBits difficulty, nonce). The nonce is the last 4 bytes of this header, and so ASICs modify bytes 76 through 79 of this compiled input when they increment the nonce.
PascalCoin, however, uses a different format for the data. The nonce is still at the end, but the length of the data is larger (and variable, although this is effectively avoidable).
For example, if I were to start mining a block right now (Total blocks = 18865), I would be hashing the following data:
91480000CA02200034EEB5BF14734D065F194567205B3CDD4A9325DAC6B7BB6CBBD0FC1EB8FC39E520001E55B0AFA322E0B057CBDA829FC420BA6A31428CA7C878BB5F642321B967BE6C40420F00000000000100000028687D22566F726B73686F6C6B2EBF663CA475EB9E3E54A26B19F757598F642F1635C22790ADE400204030F19045E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B85500000000CCDBF6579ABA8C01
Which is 176 bytes (compared to the 80 that an ASIC for Bitcoin is expecting). Also since that miner identification is part of that string, changing my miner name changes the length of this input! But the problems go deeper!
Let's step back real quick and look at how SHA-256 functions:
Initialize 8 variables h0...h7 with some starting values (hard-coded into the algorithm, they're the beginning part of the square roots of the prime numbers from 2 to 19)
Take your input bits, add a '1' bit to the end. Then, add zeroes until its length % 512 = 448. Then, append a 64-bit number which contains the length of the original message (thus making its length a multiple of 512).
Then, for each 512-bit chunk, do a word expansion (which involves dividing the 512-bit chunk into 16 32-bit chunks, performing some operations to them to produce another 48 32-bit integers, for a total of 64). Initialize some variables a...h to h0...h7. Perform a compression function that uses those 64 words to modify a...h. Afterwards, add a...h to h0...h7.
Once you've processed each 512-bit chunk in that manner, the hash is simply h0...h7 smashed together (each is a 32-bit integer, so 8 of them give you the 256-bit output).
SHA256D simply involves doing that twice. With a Bitcoin-like 80-byte input (640 bytes), the first SHA256 call will have two 512-bit chunks to deal with, so the word expansion and compression functions will run twice. The output is a 256-bit integer, so feeding that 256-bit output into SHA256 again will only have one 512-bit chunk to deal with, so the word expansion and compression functions only run once.
Fun fact: almost 2/3 of the time computing SHA-256D on a Bitcoin-style input is in the first SHA-256 run, since the 2nd one only has one chunk.Anyhow, with a PascalCoin-like (minimum ~166 byte, as far as I can gather) input, the first SHA256 call will have three 512-bit chunks to deal with, so the word expansion and compression functions will run three times. The output again is only a 256-bit integer, so the 2nd run of SHA256 would run identically to Bitcoin.
While I don't have any experience designing ASICs, I would assume that, between the different input size (meaning the location of the nonce is different than Bitcoin) and the extra SHA256 expansion/compression rounds that have to occur because of the larger input, ASICs designed for SHA-256D mining of Bitcoin-like coins would be unable to process PascalCoin hashes. However, some ASIC designs might be flexible enough to enable this or require only a minor modification to enable it.
Fun experiment you can do from home with PascalCoin and hashing speeds! With a length-10 miner name, the hashed data is 176 bytes (3 expansion/compression rounds in the first run of the algo, since this is 1408 bits input to SHA-256). However, if you increase your miner name to a length of 18 or greater (thus making the input data 184 bytes or larger, which is 1472 bytes or larger, which once you add the '1' bit, is 1473 bits, and 1473 % 512 = 449, so to get back to length % 512 = 448), we have to add an additional chunk, thus causing the first iteration of SHA256 to require 4 expansion/compression rounds.
Effectively, your miner length of 18 or greater made SHA-256 harder to compute, so you mine at a slower speed. One core of my desktop mines at 1073 kH/s with a length-17-or-below-name, but with a length-18 name it drops down to 886 kH/s (we made it go from a total of 4 chunks to a total of 5, and unsurprisingly our speed is nearly or original speed multiplied by 4/5). Note: if you change the name and your speed doesn't decrease, restart PascalCoin to force it to use the new miner name.
