consistent 66 / 33 blocks ratio in favor of pow blocks

[ghost]

There seems to be 1 hivemined block for every 2 pow blocks. ( for the whole hive, not just in a specific wallet )

It should be a 1 : 1 ratio.

The 2 : 1 ratio in favor of pow blocks seems to be always the same.

I believe this is not intended, and is a bug.

[ghost]

The community has seen that GI does not show accurate view of profit potential. This is primarily due to number of hive blocks consistently at 33.3% instead of 50.0% as originally planned. The community has created a "Honey" index that is based on this new index to accurately show potential profits in hives.

It is my understanding that hive to PoW block ratio will not change based on the time it takes for PoW blocks to come in versus consensus of hive blocks, and it has been consistent since hive activation on mainnet.

[ghost]

It's probably not a very beautifull way to code it but I got a fix :

In chain.h : CBlockIndex BackOne(const CBlockIndex pindex) const { int supertutu3 = 1; if (Contains(pindex)) return (*this)[pindex->nHeight - supertutu3]; else return nullptr; }

CBlockIndex *BackTwo(const CBlockIndex *pindex) const {
int supertutu4 = 2;
    if (Contains(pindex))
        return (*this)[pindex->nHeight - supertutu4];
    else
        return nullptr;
}

CBlockIndex *BackThree(const CBlockIndex *pindex) const {
int supertutu5 = 3;
    if (Contains(pindex))
        return (*this)[pindex->nHeight - supertutu5];
    else
        return nullptr;
}

CBlockIndex *BackFour(const CBlockIndex *pindex) const {
int supertutu6 = 4;
    if (Contains(pindex))
        return (*this)[pindex->nHeight - supertutu6];
    else
        return nullptr;
}

CBlockIndex *BackFive(const CBlockIndex *pindex) const {
int supertutu7 = 5;
    if (Contains(pindex))
        return (*this)[pindex->nHeight - supertutu7];
    else
        return nullptr;
}

And in pow.cpp :

// Check bee hash against target

arith_uint256 beeHashTarget;
beeHashTarget.SetCompact(GetNextHiveWorkRequired(pindexPrev, consensusParams));

std::string deterministicRandString;

if (numPowBlocks == 1)
deterministicRandString = GetDeterministicRandString(pindexPrev);
if (numPowBlocks == 2) 
deterministicRandString = GetDeterministicRandString(chainActive.BackOne(pindexPrev));
if (numPowBlocks == 3) 
deterministicRandString = GetDeterministicRandString(chainActive.BackTwo(pindexPrev));
if (numPowBlocks == 4) 
deterministicRandString = GetDeterministicRandString(chainActive.BackThree(pindexPrev));
if (numPowBlocks == 5) 
deterministicRandString = GetDeterministicRandString(chainActive.BackFour(pindexPrev)); 
if (numPowBlocks == 6) 
deterministicRandString = GetDeterministicRandString(chainActive.BackFive(pindexPrev));   
if (numPowBlocks >= 7) 
deterministicRandString = GetDeterministicRandString(pindexPrev); // this one will fail, but 7 pow blocks in a row is very improbable...

if (verbose)
LogPrintf("CheckHiveProof: detRandString       = %s\n", deterministicRandString);

//if (verbose)
LogPrintf("CheckHiveProof: beeHashTarget       = %s\n", beeHashTarget.ToString());
std::string hashHex = (CHashWriter(SER_GETHASH, 0) << deterministicRandString << txidStr << beeNonce).GetHash().GetHex();
arith_uint256 beeHash = arith_uint256(hashHex);
//if (verbose)
LogPrintf("CheckHiveProof: beeHash             = %s\n", hashHex);
if (beeHash >= beeHashTarget) {
    LogPrintf("CheckHiveProof: Bee does not meet hash target!\n");
    return false;
}

[ghost]

This way, it takes the right deterministicRandString if a new POW block comes in before bees has finished their work.

[ghost]

Nope. I was wrong.

I found the origin of the POW / Hive blocks ratio bug !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Now I am certain !!!! I will try to explain In the source code, in pow.cpp : GetNextHiveWorkRequired() The hive mining difficulty is adjusted with the following code : // Apply EMA int interval = params.hiveTargetAdjustAggression / params.hiveBlockSpacingTarget; beeHashTarget = (interval - 1) params.hiveBlockSpacingTarget + numPowBlocks + numPowBlocks; beeHashTarget /= (interval + 1) * params.hiveBlockSpacingTarget; I will resume what this means numPowBlocks is the number of POW blocks that have been found before the bees work to find a hive block normaly, it should be one so that there is POW / Hive / POW / Hive / POW / Hive etc. BUT the way the code is made, when there is only one POW block ( which is what we want ) before the hive block , difficulty for the next Hive block increases slightly when there are 2 POW blocks before the hive block ( which would give a 66 / 33 ratio on the long run ... ) ....... then, DIFFICULTY STAYS THE SAME and when there are 3 POW blocks, difficulty lowers slightly, 4 POW blocks, slightly more, 5, a bit more, etc. what does all that means ???? -------------------------------> THE CODE IS MADE TO HAVE ON AVERAGE 2 POW BLOCKS FOR EVERY HIVE BLOCK !!!!!!!!!!!!!! so it is MADE this way !!!!!!!!!!!!!!!!

Hive mining difficulty PULLS THE STATS to be 66 / 33 ratio, in favor of POW blocks !!!!!

[ghost]

I understand that hive difficulty could not increase if the target would be a 1 / 1 ratio, since what comes before 1, is 0 POW blocks !!! And in this case, there simply can't be a hive block......

[ghost]

Maybe hive difficulty should depend on the hive population......

[ghost]

...... or just increase the totalBeeLifespan so that the number of hive blocks correspond to what it was supposed to be ( 50 / 50 ) at current totalBeeLifespan

48 x 24 x 21 instead of 48 x 24 x 14

[ghost]

This is resolved thanks ! Great work !

[MerlinMagic2018]

This should be closed.

[litecoincash-project]

Indeed :)