Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC - page 10. (Read 217624 times)

you can't compare an orange to a table full of apples.

nicehash is a pre-paid service.   miners make X period because that's what's charged.  the value/price is set based on demand mostly.  I don't understand how you can use them as a comparison.





Yes, you get a value;  a result; an estimate.   Simple concept.... its a real world number based on..... (yeah, a calculation blah blah blah)....    Do you see the broken record's genesys yet?




part of the pool calculates on 15 min intervals, some on hourly, some on daily.  the use of these globals/functions is completely not understood by me when I looked at the code.  seemed they were mixing and matching... but couldn't make heads or tails personally.  I understand code I wrote when its that complex;  because I'm the one who created the pointers loops and references... I can see the object of the thing.   I am not going to try and do that.... I might as well write the pool code myself... not gonna happen sadly.

Maybe seeing BTC values on block rewards only after sold on exchange:  So show each coin, the percentage earned, and BTC value as it does now;  but have it show after confirmed and sold... not before sold on exchange;  only show block percentage credit until that point?

But honestly;  that would $#%@ up the whole thing.  Its nice the way it is....  Profitability is still thumbs up....

Maybe just update the word estimate where needed on the wallet page...

so i cant say result to the values/algos returned by the call/server? "the result of an api call" sounds far better than "the estimate of an api call"

however i think you get my point but dont want to comment on it

The estimates are comparable but not relevant to the issue. The only difference is Nicehash's estimate is also the actual (the current estimate,
not the daily profit estimate) while with real pool mining there is luck, orphans, and time risks. Statistically, orphans are a pure negative risk,
luck should be neutral over the long term and time risk is unpredictable. But these risks are not part of the problem, they
are well enough understood by all but the noobest.

Tracking the pending estimates appears to be working correctly as the value fluctuates with the exchange rate as the block matures. It goes up
and goes down, all normal.

The problem is when the block is sent to the exchange, suddenly the value drops 20%. That's a pretty precise problem definition. It's not difficult
to prove, the data is available, just not to users. It seems the only one that has access is not interested in looking at it but has the most to lose
over it. You don't need to be a code monkey to understand logs.

Like I said I added a 20% discount to zpool estimates and my daily revenue has risen by 10 to 15%. It works for me.

if you dont want to compare them to "realtime pps" at least compare them on zpool itself, the api and the pool itself (described in multialgo switching on zpool.ca) serve different algos based on profitability, which is not giving appropriate results

afaik (correct me if im wrong) the estimates are based on exchange rate, difficulty and likely some more parameters, assuming the exchange rate stays +- the same (assuming the ttf and exchange timeframe is short) this should be possible as shares are rewarded by PPS?

i can only guess, but i assume you are talking about sha256 mining with asics? if so this is completely irrelevant as it does not multi-pool-multi-algo switch but is a statically configured miner setup to mine on this pool which does not use the api at all

my last 7 day average is
0.00896 per day..

its not too bad.. i would be getting around 0.007238 per day minus fees mining on bitcoin pool.

For me its not only an issue with the estimate of confirmed/unconfirmed alts converted to btc are FAR less, but also the myself calculated profitability of my rig(s) based on the api matching the results i could get (confirmed/unconfirmed) and not the "actual" profit.
If the later wasnt true my calculations would work fine and my miners would not select zpool if nicehash (eg) would be more profitable at the current time.
But sadly it isnt. Reducing the estimate (api that is) by a fixed amount that is vaguely guessed (*0.65) does not result in a correct estimate and thus i will "switch", in my case disable zpool.

I have seen much effort on his part to try and figure it out.  I have seen posted logs many pages ago... so the broken record, while being equal on both sides, the user-end seems to keep pushing the needle back a few tracks each time and wondering why the audio keeps sounding the same.

Logic, logic logic.    Please... don't dismiss the answer just because its not what you wanted to hear.... especially hearing it from many people whom have tried to help such as I.

the word "Confirmed" on the wallet page only applies to the Block reward:  not the ficticious BTC or other altcoin conversion you are seeing associated with it that is being shown by some sort of calculation.



I will agree:  these problems were not as visibly present in the past, but back then, some of us users were noticing a 20% discrepency in the hashrate-to-payout ratio, yet, the payouts were right on par with profitability or better.    Some weeks or months down the road, a commit was put up and the pool was probably updated; and all the sudden we see things like reject graphing and magically the "20% missing total share" was gone  and this issue popps up.....  (silence from the crowd now about the first issue)

Im no rocket scientist... but my profitability has stayed round about where it always has been or what I was expecting. (factoring in for larger network hashrates and the BTC halving rippling down the profitability line, etc.)  Through the powers of deduction we can all come to a rational assumption about all of this.

Sadly, most people arent rational, and things stoop to the lows we are now seeing.

An estimate: "an approximate calculation or judgment of the value, number, quantity, or extent of something."


Its pretty simple:  Do not hold a number you do not know how is calculated at face value; because flat and simple, you don't know how its derived...

desynct:  I understand its frustrating... but... people are counting their chickens before their eggs are hatched, and getting pissed at him because they haven't...   You don't get pissed at the farmer because the hens that laid the eggs that didn't all hatch that didn't weigh as much as you expected when they went to market.... that's just idiotic thinking.  It's bad behavior no matter how you look at it.

This pool code is 100% different than the others out there.  It can not be compared to "this pool works this way while zpool works that way".... that's a no brain-er as well.

You're the broken fucking record, always the same excuse. I haven't asked you to fix it just investigate it. I've even suggested exactly what to
look for in the logs and offerered to do the dirty work myself, but always the same lame excuse. You've been around long enough, it doesn't fly.

no it is personal SP_MOD#6. but other miners from tpruvot  (1.8.1) or klausT (8.00) are even worse. How much can I squeeze from gtx 1070 ?

I was actually going to suggest this last night.  I think they are all useless.


As for the issue with estimates:

Look up the English definition of the word estimate.


Now.  Let it sink in that it is NOT A STATIC NUMBER.   It is a GUESS, based on an UNKNOWN calculation.   What does not make sense about any of that?



You are ASSUMING.  When you assume, you do exactly what the word spells:  you make an ASS out of U and ME.


Please let it go, or switch pools.   Plain and simple.



Crackfoo, maybe change front end wording to say something like "guessed amount mined" or something.   Might conpute better....


But it would kinda stink to loose the early pre-confirmed data.

Are you using opensource sp ccminer? If yes, it does have a bug, causing it to show higher hashrate than real. I've posted the fix some time ago, but there is no precompiled binary available yet.

Auto adjust. But it does not matter because with specific diff it is the same. Before the stratum address change it was working fine.
Maybe you should know, that the miner sometimes displays wrong nonce or dupplicate nonce or sommething like nonce sent xx seconds ago. But that is not too otfen and all miners are displaying it.

are you using a specific diff or allowing it to auto adjust?

really though.

skein. Miner says 520 and on my wallet page is approx 500. but after 8 hours it starts dropping to 420. I have tried different miners from tpruvot or klausT but that is even worse. These miners hashing 450 or 520 respectively but on the wallet page there is only 360 or 420 respectively. I have Gigabyte gtx 1070 G1 and Pentium G3220 with 8GB RAM.

not sure. what algo are you using? haven't seen any other reports of similar issues.

no, just tired of the broken fuckin record. The code is there, I didn't build it, nor am I a developer and nor did the current dev build it. If you know where the issue is, submit the code fix to the open source repo and I'll happily pull and merge it into zpool.

I have nicehash miners running now almost since the pool started and the continue to earn so it's not really my problem to cradle everyones testicles to make them feel good. The pool is profitable so if you can't figure out how to do it properly why am I responsible? Whats the secret? Hire a developer to build you your own intelligent bot.