RESOLVED: Seems this bug is still hanging around.....

GenTarkin wrote:Question ... is the live worker status a "Verified Status?" as-in when it says Im mining a specific coin, has it verified that against the shares my miner returns or is the live worker status just a "miner supposed to be mining this coin so we are going to assume it is..." type?
If it was the former then its likely its just the way bfgminer is reporting its work for some reason and its lieing, if its the latter then I guess its still possible that the miner is indeed mining the wrong coin as I suspect.

The assigned coin is based upon the work we are sending you, not the shares you are submitting to us. The rest of the statistics are based upon the work you have submitted to us.

Chris Sokolowski wrote:

GenTarkin wrote:Question ... is the live worker status a "Verified Status?" as-in when it says Im mining a specific coin, has it verified that against the shares my miner returns or is the live worker status just a "miner supposed to be mining this coin so we are going to assume it is..." type?
If it was the former then its likely its just the way bfgminer is reporting its work for some reason and its lieing, if its the latter then I guess its still possible that the miner is indeed mining the wrong coin as I suspect.

The assigned coin is based upon the work we are sending you, not the shares you are submitting to us. The rest of the statistics are based upon the work you have submitted to us.

Ok, so sounds like its the latter case which I described , which still leaves the issue open =/

I do have a theory tho as to it possibly being just displayed / reported incorrectly as per bfgminer. My theory is similar to your initial one. Although, Id still like to see if you guys can confirm that my miner was indeed sending the right shares back to you as per my previous post w/ screenshot.

My theory is this:
1. Lets say LTC block 100 is being mined.
2. Pool issues jump to a coin w/ higher profitability for say 15 seconds(doesnt matter the block number).
3. The higher profit coin is no longer profitable so pool sets work back to LTC.
4. LTC is still on block 100 so bfgminer states "pool issuing work for older block", bfgminer still acts like its mining on the higher prof coin(the delayed switch back to LTC(in this example) that Ive been talking about since OP). But, in reality bfgminer is sending shares back to LTC block 100 correctly even tho it shows that its not.

Now, Im thinking if LTC block 101 was the block which was switched back to then bfgminer wouldnt say "pool is issuing work for an old block" and it would update the TUI just fine showing the LTC block / diff. (this scenario is when it shows that it switched back to LTC correctly).

When you think about it, this could happen on any coin switch for any reason. As long as the switch back to any coin was on that coins same block height then bfgminer will show this message and not update the TUI correctly.

Like I stated tho, I would still like you guys to verify the shares being returned in such circumstances .. are for the correct coin tho. But, Im highly suspicious what I outlined above is actually whats happening.

I did some more research into this and determined that what you think is the correct answer.

The only difference is that the way it determines if an "old" block is being mined is because it tracks it by previous hash, not by network or difficulty. The previous hash uniquely identifies a block and the mining software must keep that in memory.

Even though it reports that, it still submits the correct block (the one it warns is "old.") But it thinks that we are trying to find blocks at the difficulty of the easier network. The share difficulty remains unchanged, so it submits shares correctly, but the mining software thinks it is finding blocks very frequently when it actually isn't, because the server isn't confused between coins. This explains another reported issue, where some miners say that blocks aren't appearing on the "last found blocks" list even though their mining software is reporting them. They think the pool is wasting blocks when it's actually the client reporting incorrectly.

Chris is going to test a fix for this tonight. The fix is to set clean_jobs to False in the stratum messages every time new work is sent, unless the new work is sent because a litecoin block was found. The theory is that the reason the mining software thinks these blocks is "old" is because the value of clean_jobs caused it to think they were old.

If this works, it will get rid of the error messages and the number of blocks found will match what the server reports. I don't think profits are affected at all by this issue, but we may be pleasantly surprised to find that other issues are resolved at the same time.

Steve Sokolowski wrote:I did some more research into this and determined that what you think is the correct answer.

The only difference is that the way it determines if an "old" block is being mined is because it tracks it by previous hash, not by network or difficulty. The previous hash uniquely identifies a block and the mining software must keep that in memory.

Even though it reports that, it still submits the correct block (the one it warns is "old.") But it thinks that we are trying to find blocks at the difficulty of the easier network. The share difficulty remains unchanged, so it submits shares correctly, but the mining software thinks it is finding blocks very frequently when it actually isn't, because the server isn't confused between coins. This explains another reported issue, where some miners say that blocks aren't appearing on the "last found blocks" list even though their mining software is reporting them. They think the pool is wasting blocks when it's actually the client reporting incorrectly.

Chris is going to test a fix for this tonight. The fix is to set clean_jobs to False in the stratum messages every time new work is sent, unless the new work is sent because a litecoin block was found. The theory is that the reason the mining software thinks these blocks is "old" is because the value of clean_jobs caused it to think they were old.

If this works, it will get rid of the error messages and the number of blocks found will match what the server reports. I don't think profits are affected at all by this issue, but we may be pleasantly surprised to find that other issues are resolved at the same time.

Yeahp! Sounds spot on =) ... I figured it was by blockhash anyways, was just keeping it block# for simplicity sakes =P
My only concern is if you issue a clean_jobs to the mining software .. will that result in any actual work restart / queue penalty as far as the mining hardware is concerned? I wouldnt think so because, Id imagine the mining software has to flush / update the work on ANY block change regardless of historical blocks.
In regards to the workaround. I think that clean_jobs message needs to be sent not only in litecoins case but anytime there a switch *BACK TO A COIN* that has the same block hash as it did prior to the switch to a different coin. Why not just set clean_jobs as you stated each time a coin switch is done, but avoid doing it when a new block is found for a coin already being mined on.

And you are definitely right as far as that other bug people reported! I used this to verify my theory since my last message. Anytime I saw a block was found (by my miner) on a coin switch which appeared to be "stuck"(in the manner I previously described) ... I would check the pool user block found list and if it wasnt on there ... this verified my theory was true =)

The important thing is, the shares seem to have been correct all along. Is just a client side bug, and good to know theres a flag you can set in protocol that may fix this issue =)

Now the only thing Im confused about is ...
Why does the calculator on litecoinmining.org & clevermining & nicehash all specify that 1MH/s LTC yields roughly .000075btc/day currently(funny how even tho all 3 of those pools are fundamentally different ... they are so close to same return) .... while prohashing shows it being around .000065btc/day (according to the live coin status).
Is it because the live coin status calculates based on (1MH/s BTC RATE * ( 100 - ( 5% prohash fee + LTC 8% orphan rate))) / 100
If so, thats a huge loss =(

Traditional PPS pools pay on orphans, because they pay on all shares.
I notice the banner across top of pool states the .00007x rate .. which is for the previous day I take it ... so you may not be that far behind actual LTC pps as indicated by litecoinpool.orgs calculator. The crappy part is, it seems the 13% fee(pool fee + orphan rate of coins(which of course changes the fee)) is whats preventing the pool from barely doing better than just mining straight LTC pps .. like at litecoinpool or even using nicehash for autoconvert to btc @ current market rate which s 100% LTC pps or greater almost all the time....

GenTarkin wrote:Now the only thing Im confused about is ...
Why does the calculator on litecoinmining.org & clevermining & nicehash all specify that 1MH/s LTC yields roughly .000075btc/day currently(funny how even tho all 3 of those pools are fundamentally different ... they are so close to same return) .... while prohashing shows it being around .000065btc/day (according to the live coin status).
Is it because the live coin status calculates based on (1MH/s BTC RATE * ( 100 - ( 5% prohash fee + LTC 8% orphan rate))) / 100
If so, thats a huge loss =(

Traditional PPS pools pay on orphans, because they pay on all shares.
I notice the banner across top of pool states the .00007x rate .. which is for the previous day I take it ... so you may not be that far behind actual LTC pps as indicated by litecoinpool.orgs calculator. The crappy part is, it seems the 13% fee(pool fee + orphan rate of coins(which of course changes the fee)) is whats preventing the pool from barely doing better than just mining straight LTC pps .. like at litecoinpool or even using nicehash for autoconvert to btc @ current market rate which s 100% LTC pps or greater almost all the time....

We do not include the pool fee in the LTC calculation; the only deduction from the theoretical maximum is the fixed 2.5% expected LTC orphan rate that Steve hardcoded (our actual LTC orphan rate isn't part of it). For your information, these are the exact LTC profitability numbers (in BTC/MH/s/day) that were reported for the past 7 days:

2016-07-08 0.000067740847338692300000
2016-07-09 0.000065024629835180200000
2016-07-10 0.000064031338650518500000
2016-07-11 0.000063543242612001300000
2016-07-12 0.000063713675234912700000
2016-07-13 0.000072418095693349400000
2016-07-14 0.000073186389505059400000

I think the discrepancy can also be due to one other factor. We report Litecoin difficulty averaged over the entire day, whereas others use the Litecoin profitability at the time they generate their charts. So on a day like July 12 where the Litecoin difficulty dramatically dropped, we reported a lower profitability because the difficulty was high for most of the day. The days could also be slightly different because of time zones.

Regarding your comment that "Traditional PPS pools pay on orphans," we do pay on all valid shares, whether they find an actual block, an orphan, or no block at all. We do have the orphan penalty, but I see no way we could operate without it. That paradigm of not charging an orphan penalty and including it in the pool fee only works when you're mining one coin that has a constant orphan rate. We must have an orphan penalty because each network has a different orphan rate, and that orphan rate directly affects which coin to choose to mine. I don't think you can generalize orphan rate on a coin-switching pool because it ranges from under 1% for most coins where we seem to be the only miners on the network to 38% on WildBeastBitcoin because of the coin's wild difficulty swings where a lot of pools join in on easy blocks.


On another note, we deployed a change to the mining server that Steve believes will resolve the main issue of this thread. I haven't seen a change with our miners, but I would like your report on how it works.

Yeah nothings changed, it still reports pool is issuing work for old block. I even restarted the miner. =(
Thanks for the explanation of profitability, not sure I understand it all. Still seems like the numbers dont all add up .. the 3 pools I mentioned show LTC 100% BTC pps rate @ .00007+ ... this pool shows it at well below that(.000065ish) in the live coin stats.(going off the pre diff increase numbers).

Its hard to tell when everything is pegged to $ lol! ... Im not sure why pool is set up this way. Wish it were all pegged to crypto currencies, mainly BTC ... would make stats interpretation much easier.

Think what I will do is load-balance mine nh, clevermining & prohash for next few days and compare the results =)

The reason we based our system off dollars is because we still are not sure if Bitcoin has a future; the outlook on the U.S. Dollar is much better. Still, we are looking into potentially supporting other currencies for display such as Bitcoin and the Euro.

None of my miners will mine proper as of today.

Gblades always 15Mhs... Today 10Mhs
Gblack always 25Mhs..... Today 19Mhs
A2 Always around 100Mhs Today 56MHs??

Sent the Gblack to litecoinpool and mined great.

Don't know whats wrong but never seen it this bad.. I have unhooked for now don't have time to test.. Was something recently changed?

Basically from my comparison of mining here and at a straight LTC pool, if LTC difficulty is high where I earn less mining LTC then I can be slightly more profitable here. If LTC difficulty drops then I'm more profitable on the LTC pool unless some anomaly like the Yocoin bubble occurs.