Re: [ANN][ANC] Anoncoin (anoncoin.net) | Privacy-centric currency | I2P darknet
This is a Scrypt coin, obviously nothing was changed has to how much the hashrate and proof of work target are related to maintain the targetspacing for a typical average network hashrate.
If you want to use a value for your Scrypt multipool automatic switching to the most profitable coin, I leave it to yourself to calculate the best profitability vs other coin. All the difficulty values are in fact not comparable already, being different for different target spacing, and to use the reciprocal of anoncoin difficulty in your jumping script is not difficult. I will not help you further for that as we prefer to support the long term miner over multipools, and also because I do not see what issue you have in this.
The standard difficulty will from now on be always between 1 and 0. This is what the PID is programmed to use, and is the target requested by the block at the tip.
1 is the lowest difficulty.
The more leading zero there is after the decimal separator, the more difficult it is to find a block.
The lower the significant figure, at constant number of leading zero, the more difficult it is.
Difficulty zero will never happen, but could be displayed if hashrate reach thousands of GH/s, because in fact the difficulty as displayed by getdifficulty is just a troncated representation of the minimum hexadecimal target to find the block at the tip of the chain, which is a 256 bit number.
I am sure people will get habituated, meanwhile just use the reciprocal, ie 1/difficulty to get an idea.
Otherwise, your miner program will display the difficulty in the reciprocal format.
Ok... so to compare ANC difficulty to other scrypt coins?
If you want to use a value for your Scrypt multipool automatic switching to the most profitable coin, I leave it to yourself to calculate the best profitability vs other coin. All the difficulty values are in fact not comparable already, being different for different target spacing, and to use the reciprocal of anoncoin difficulty in your jumping script is not difficult. I will not help you further for that as we prefer to support the long term miner over multipools, and also because I do not see what issue you have in this.
So after block 555 555 we'll see the standard difficulty number or will it still be between 0 and 1? How do we get a comparable scrypt difficulty?
The standard difficulty will from now on be always between 1 and 0. This is what the PID is programmed to use, and is the target requested by the block at the tip.
1 is the lowest difficulty.
The more leading zero there is after the decimal separator, the more difficult it is to find a block.
The lower the significant figure, at constant number of leading zero, the more difficult it is.
Difficulty zero will never happen, but could be displayed if hashrate reach thousands of GH/s, because in fact the difficulty as displayed by getdifficulty is just a troncated representation of the minimum hexadecimal target to find the block at the tip of the chain, which is a 256 bit number.
I am sure people will get habituated, meanwhile just use the reciprocal, ie 1/difficulty to get an idea.
Otherwise, your miner program will display the difficulty in the reciprocal format.
Ok... so to compare ANC difficulty to other scrypt coins?
OK I understood your question, which indeed was a meaningful question! Thank you to have asked it.
The new command 'getnetworkhashps' is what you need to get the most accurate approximation.
Code:
02:59:18

help getnetworkhashps
02:59:18

getnetworkhashps [blocks] [height]
Returns the estimated network hashes per second, optionally for a given height and based on the last n blocks.
Arguments:
1. blocks (numeric, optional, default='tipfiltersize') Hint: The 'getretargetpid 1' query tells you the tip filters size.
2. height (numeric, optional, default=0) Default to current chain tip, or specify at what height the calculation is to be made.
NOTES: Block spacing is measured, so at least 2 blocks are needed to calculate one spacing interval, the more the better.
Pass in [height] to estimate the network speed at the time when a certain block was mined. Pass in [blocks] to override the # of
blocks used in the calculation, any value < 2 sets the min of 2 blocks. Expect a poor estimate, with so few.
Result:
(numeric) Estimated hashes per second, the calculation made is the chain work proofs (latest - oldest) / time delta.
Examples:
> anoncoin-cli getnetworkhashps
> anoncoin-cli getnetworkhashps 200 350000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnetworkhashps", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:9376/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnetworkhashps", "params": [5000,390000] }' -H 'content-type: text/plain;' http://127.0.0.1:9376/

help getnetworkhashps
02:59:18

getnetworkhashps [blocks] [height]
Returns the estimated network hashes per second, optionally for a given height and based on the last n blocks.
Arguments:
1. blocks (numeric, optional, default='tipfiltersize') Hint: The 'getretargetpid 1' query tells you the tip filters size.
2. height (numeric, optional, default=0) Default to current chain tip, or specify at what height the calculation is to be made.
NOTES: Block spacing is measured, so at least 2 blocks are needed to calculate one spacing interval, the more the better.
Pass in [height] to estimate the network speed at the time when a certain block was mined. Pass in [blocks] to override the # of
blocks used in the calculation, any value < 2 sets the min of 2 blocks. Expect a poor estimate, with so few.
Result:
(numeric) Estimated hashes per second, the calculation made is the chain work proofs (latest - oldest) / time delta.
Examples:
> anoncoin-cli getnetworkhashps
> anoncoin-cli getnetworkhashps 200 350000
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnetworkhashps", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:9376/
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getnetworkhashps", "params": [5000,390000] }' -H 'content-type: text/plain;' http://127.0.0.1:9376/
By default, it use the tipfilter size which is 21 block, but then the value will fluctuate according to the time it took to find those 21 blocks as given by the TipsAvg. If you want to know on a broader timescale, you shall use at least 120 blocks, which is the last 6 hours average. You can see from the GroundRod PID graphs that both the TipsAvg and Difficulty value will be then precise enough for the calculation of the getnetworkhashps.
Code:
03:15:02

getnetworkhashps
03:15:02

3268971239
03:15:04

getnetworkhashps 21
03:15:04

3268971239
03:15:06

getnetworkhashps 2
03:15:06

393059443
03:15:10

getnetworkhashps 120
03:15:10

4120719633
03:15:16

getnetworkhashps 480
03:15:16

3780644272

getnetworkhashps
03:15:02

3268971239
03:15:04

getnetworkhashps 21
03:15:04

3268971239
03:15:06

getnetworkhashps 2
03:15:06

393059443
03:15:10

getnetworkhashps 120
03:15:10

4120719633
03:15:16

getnetworkhashps 480
03:15:16

3780644272
The value of your hashrate, divided by the 'getnetworkhashps' value will be the most precise to know how much percentage blocks you shall get on a time period, especially after the PID is activated which shall render the mining much more stable on a several blocks time period than KGW.