AcceptBlock() : too many blocks found using same algorithm

[Heraisu]

So, I came across this issue with my pool. It seems that there are times when mining a block is guaranteed to get you a rejected block even if you find a valid solution... How would one use RPC to check for this state (so algo profit switching doesn't direct miners to a coin which cannot currently be mined)? Thanks.

ThreadRPCServer method=submitblock ERROR: AcceptBlock() : too many blocks found using same algorithm ERROR: ProcessBlock() : AcceptBlock FAILED

[Heraisu]

This is happening around 40-50% of the blocks on Lyra2 today... pulling VERGE until we see an answer.

[marpme]

Well on the verge daemon you can check which algorithm is currently being used.

~/work/VERGE(master*) » ./src/VERGEd -rpcuser=kyon -rpcpassword=lolcat getinfo                                         marpme@Marvins-MBP-2
{
    ...
    "pow_algo_id" : 0,
    "pow_algo" : "scrypt",
    "difficulty" : 52403.69164694,
    "difficulty_x17" : 4120.85734983,
    "difficulty_scrypt" : 52403.69164694,
    "difficulty_groestl" : 551284.95903074,
    "difficulty_lyra2re" : 13239.32047903,
    "difficulty_blake" : 6596164.37130670,
    ...
}

The pow_algo field will tell you, which algorithm is currently being used and the difficulty field will automatically adjust alongside with the pow_algo field. Maybe this can help you a bit?

[Heraisu]

pow_algo tells you which algorithm you booted it with, scrypt being the default (id=0), in my case lyra (id=2) is what it's running as for POW. But it appears that, although it will give Lyra work and has a current lyra pow_algo and a lyra difficulty value... the daemon will not accept solved blocks for lyra if (interpreting the error message) too many of the previous blocks have been solved on the same algo? Complete waste of work.

[marpme]

I kept watching the algorithm state and for me it switch between all algorithms. But I have also not specified any algorithm inside the VERGE.conf

but I'm quite unsure if this is really a solution to your problem, let's see if @jrsikors or @justinvforvendetta does have an idea.

[justinvforvendetta]

which pool do you run @Heraisu

[a1binos]

This is not an issue, but a cure for double spending attack. You cannot mine too many blocks of the same algo in a row, for example, by renting some hash power from the service, like NiceHash. If some one will try to hash with big rent power, he will lose his blocks=money. This is a good practice for multi-algo coins.

[jrsikors]

I concur @a1binos , it's "working as designed" and this situation is an unfortunate casualty of the war against exploitation.

To his initial concern (I dont know the answer) , is there a way for a pool operator to be able to tell this in advance via RPC commands?

[a1binos]

I don't think, it is a good practice, to tell such information in public, because, if you know how to do it, it is easy to make a 51% attack and double spending attack for the bad guys, that may read this issue and make some decisions. And anyway, it leads to concentration of blocks in 1 hands, that is bad.

[jrsikors]

I'm just thinking in terms of a simple script like: "If Last5Blocks = Lyra then OKToMineXVGOnLyra = False, else OKToMineXVGOnLyra = true"

[jrsikors]

Even if that logic wasn't 100% accurate, at least it would give a pool operator the chance to bail if there was even a chance the block would get rejected... to be on the safe side 100% of the time.

[Heraisu]

I understand it was to avoid NiceHash etc., but it's still expensive, and there must be a way to better avoid double-spend (it's very easy to rent more than one algo from NiceHash anyways, so I'm not sure how this helps). I would LOVE something like what @jrsikors posted above. Basically, I can never trust mining it and the profit calculations will never have enough "negative luck" scalar for "whoops might also be worthless work we're sending you."

I'm actually having trouble finding a block explorer online that shows which algo each block was or something where I can run a quick query to see how often this happens. Yesterday was brutal though.

I appreciate the feedback.

[justinvforvendetta]

http://poolovich.pro/explorer/XVG http://poolovich.pro/explorer/XVG

[Heraisu]

Also, is that the actual value? Last 5 blocks will reject any further ones of the same algo? But as soon as the highest block has a different algo, it will work again?

[jrsikors]

I don’t know if 5 is the magic number.. or if there is a magic number. A quick look at the link Justin provided looked like there were 4 in a row a couple times. Will need to look at more samples to try to gauge

On Jun 16, 2018, at 4:40 PM, Heraisu notifications@github.com wrote:

Also, is that the actual value? Last 5 blocks will reject any further ones of the same algo? But as soon as the highest block has a different algo, it will work again?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jrsikors]

So are you good with the link justin provided and 4 as the number?

[Positivism]

Is 4 the magic number? http://poolovich.pro/explorer/XVG?start=2284185 Shows 5 lyra.

2284179 - 2284183

[Heraisu]

I guess this can be closed if it's intended as way to punish pool mining, it's working as intended. But it's not achieving the desired goal. Just look at the histogram of Verge in Lyra ... insane swings.

EDIT: To answer the above, from looking at the source code it appears to be 5.

[justinvforvendetta]

it's not a punishment to pool mining at all. and what do you mean look at lyra? the diff goes up and down, but i dont see any "insane swings". you can see it here, hourly, or by 12 hour, etc.. https://vergecurrency.network diff goes up and down, but nothing too dramatic from what i see.

[jrsikors]

As @a1binos pointed out -- we know it's not ideal -- but it's good practice for multi algo coins. If some people in this world didn't suck as human beings and tried to steal/hack/exploit , this "too many blocks in a row" wouldn't be necessary.

@justinvforvendetta -- do you know if that's for sure how the logic works, assuming 5 blocks in a row is the max in a row limit? if it's: Block 1: lyra2v2 Block 2: lyra2v2 Block 3: lyra2v2 Block 4: lyra2v2 Block 5: lyra2v2 Block 6: blake2s Block 7: ???

So 5 lyra2v2 in a row ... and the next block 6 is non-lyra2v2

Can block 7 now by lyra2v2 again in that scenario?

[jrsikors]

Block 1: lyra2v2 Block 2: lyra2v2 Block 3: lyra2v2 Block 4: lyra2v2 Block 5: lyra2v2 Block 6: blake2s Block 7: lyra2v2 Block 8: lyra2v2 Block 9: lyra2v2 Block 10: lyra2v2 Block 11: lyra2v2

Is this scenario allowed to happen? 5 lyra2v2, next blake2s, then 5 more lyra2v2 ?

Or is there more complex logic in there that won't allow 10 Lyra's in 11 blocks, even if a different algo is right in the middle?

[justinvforvendetta]

yes this is allowed, but with a lower drift like we have now, the previous attacks dont work because they require about 2 hours of mining on a seperate chain

[Heraisu]

@justinvforvendetta I see your graph but I don't understand why it seems so smooth. Perhaps it's not precise enough to see the swings I'm talking about? Just now I checked to respond, and the most recent blocks for Lyra vary between 20999 and 1246 in a 10 minute time frame... over an order of magnitude change. Marking start point for people checking this link in the future: http://poolovich.pro/explorer/XVG?start=2286536 I'm replying to back up my statements, but I do understand this is "working as intended" so again I will not be offended if the issue is closed to clean up the backlog.

[justinvforvendetta]

well, when the network is in the low 1k's for difficulty on lyra2, id assume a multipool jumps on and starts mining. alot of large multipools for scrypt and lyra2 do this for profitability when a particular algorithm is at a low.

[Heraisu]

So what does the "5 blocks only" do except punish consistent miners? Difficulty goes up if it gets hammered, as it should. When difficulty goes low, 5 blocks are quickly mined and then the switches exit, leaving constant miners disproportionately putting their hash time into the highest difficulties and also being the ones left to get the TooManyOfSameAlgo block rejections, yes? It's like a double-whammy for the non-switching miners, and what does it achieve that dynamic difficulty doesn't already? Is there an explanation somewhere for the reason for the policy?

[a1binos]

The reason is equally reward distribution between algos. And to keep NiceHash away from this coin. So a particular miner on a particular pool on a single algo gets more profit, because with constant hashrate per algo, there is no chance to make 5++ blocks on the same algo. With NiceHash on, there is no need to mine this coin constantly: on a higher diff, you slowly cranking blocks, when diff go to low, you are out of blocks: came big hash power from NiceHash and took away your reward. So, you are slowly mining only high diff blocks, while other guys mine only on fast low diff blocks. That is no fair for a single miner, so, this 5 blocks rule works perfect. 👍

[justinvforvendetta]

yeah, if pools didnt exist, and people could only solo mine, then i could see these rules as bad, but for now, they seem to be the most fair.

[Heraisu]

Timezone: PST Today it happened in the extreme, again, except I have no idea why. A series of 5 blocks were not detected, and the explorer does not show any such series around this time. 9 potential blocks were found between the time of 4:19 and 5:27 (sudden drop in difficulty, I assume), however, in the middle of those, 5 of the blocks were rejected and the log says "too many of the same algo"... from 5:22 to 5:26... can you please explain whatall triggers this? Because the blockinfo had myr-gr on the head when this happened... even querying the blockchain before mining and submissions from the daemon itself, the most recent 5 counts were NOT Lyra at any point. Heck, not even the last 4. Yet we get block rejections 5 times. XVG had been readded with an extreme bias multiplier against the alleged reported difficulty, but regardless, this coin just isn't for profit switching pools, is it?

Add: It was around here when the alerts started coming in en mass... http://poolovich.pro/explorer/XVG?start=2293384

[justinvforvendetta]

are you mining on clearnet or master branch? I'm guessing the answer is latency in the block submission

[Heraisu]

@justinvforvendetta https://github.com/vergecurrency/VERGE/issues/764

[oliverw]

@justinvforvendetta But it sure looks like a punishment for pools. https://coinfoundry.org/pool/xvg1 has more blocks rejected for that reason than actually mined. Not even mentioning the orphans.

[Positivism]

This is why I stopped mining verge, it's currently just too unprofitable. I opened an issue #807 to alleviate this while maintaining security.

[jrsikors]

We are closing ALL issues to get a clean slate after the major codebase update. Please re-submit issue with details if this is still an issue moving forward.