But it's still interesting to me, where does that ~19 GH/s come from? I mean, someone or some pool with that amount of hashpower should clearly know that they're not getting reward for their hashrate. I think it could be a pool whose settings gone totally wrong. getdifficulty output:
{
"proof-of-work" : 274.46071294,
"proof-of-stake" : 0.00367996,
"search-interval" : 1
}
To expand further on where these numbers come from..
So NetHashRate uses the GetDifficulty() and timestamps from blocks to calculate.. (thats why it may seem variable because timestamps differ.. so it'll bounce around 18-19..
GetDifficulty() itself basically returns the *last* block that was proof of work. And thus it's always stable.
The code is just a while loop that keeps searching the prevblock index until it finds a block that was done via PoW:
const CBlockIndex* GetLastBlockIndex(const CBlockIndex* pindex, bool fProofOfStake)
{
while (pindex && pindex->pprev && (pindex->IsProofOfStake() != fProofOfStake))
pindex = pindex->pprev;
return pindex;
}
double GetDifficulty(const CBlockIndex* blockindex)
{
// Floating point number that is a multiple of the minimum difficulty,
// minimum difficulty = 1.0.
if (blockindex == NULL)
{
if (pindexBest == NULL)
return 1.0;
else
blockindex = GetLastBlockIndex(pindexBest, false);
}
And.. I guess that must have been the last block at 20160... yep, last PoW block difficulty was indeed locked at : 274.46071294.
getblockhash 20160
0000000000bd301676a0e57aeb7c63165f875dd015ed2e44262a41ce3feca390
getblock 0000000000bd301676a0e57aeb7c63165f875dd015ed2e44262a41ce3feca390
{
"hash" : "0000000000bd301676a0e57aeb7c63165f875dd015ed2e44262a41ce3feca390",
"confirmations" : 12230,
"size" : 5540,
"height" : 20160,
"version" : 4,
"merkleroot" : "47105789d11856e5f2cea3356a3d3e4f57e3387fc3e0f0f5be80e44ef57f232c",
"mint" : 5000.03700000,
"time" : 1398926850,
"nonce" : 4172128409,
"bits" : "1c00eec7",
"difficulty" : 274.46071294,
"previousblockhash" : "0000000000b94ea70342a8219e89b8bcf6c6f402e90bf493996942b64e8bfb5e",
"nextblockhash" : "99dbd72ce0b370df3b6dad5d61be279ce874aa5cbfc3accbcb69ab1bedee89e7",
"flags" : "proof-of-work",
"proofhash" : "0000000000bd301676a0e57aeb7c63165f875dd015ed2e44262a41ce3feca390",
"entropybit" : 0,
"modifier" : "5b13c49e3d59da47",
"modifierchecksum" : "76639dba",
"tx" : [
"640666e861238d5212b78219a68b329f4de1642cfc92d92e683f445a78f07ff6",
"397b22d78097de1619a70dd7891218c4f014e2ac36954c27a788c38740c6d151",
"d510fcf164267a0bf44bf9bc7d39cd9d4f851bad5d65fd9cfb61e1fbc8114e48",
"f724ce029cad2a88281d81bb0e5081c9d573a65eb756b096f3e59fc5c767ecaf",
"838ea24c4d87c97344c5334cda4870d8dfcfc530abb5507244b1c0c45c8e1b49"
],
"signature" : "3044022076f574731c818943b983d8460fe99ca02f27f4f494cf421bfdd83aec9820dc2002202e7c2da59be560228af0e3614d2dc1adf9d40db5218c6c48257c3ed6cd4085bd"
}
So in a very simple sense: the RPC calls for getmininginfo and getdifficulty are showing the frozen state of the last PoW block difficulty and nethash rates.
I think when everyone cloned their coins from ppcoin, which was supposed to be a PoW/PoS coin.. moving to 100% PoS, a lot of the RPC calls were never modified to take this into account to return the proper information.. PPcoin wasn't designed to be a 100% PoS coin to begin with...
I bet rat4 and others may be updating the code under blackcoin to clean up some of this stuff.... or i can just update it.. but this stuff is just informational data through the RPC calls, it doesn't factor into actual operations..
), but there must be a precise way to control/manage this. I don't think the challenge is the implementation of it into code, it's figuring a viable model out.
