very little proof... a very small dataset....  Just a graph showing an estimated value becoming an actual value....

Let me expand:
What were the rest of the statistics for those specific payouts to the wallets?

How were the estimates derived mathematically?  What variables are in that calculation and in what order to provide this result?


SEE WHAT I AM SAYING YET?

See how I keep pointing out there's more variables than people choose to focus on.

you misread as I state that's an issue that needs looked at in my reply above.

so you are telling me that you are certain you were earning 100% block reward  (by share submission) and no other miners has delta hashrate left over from a previous connection at that same time as your test?

Again, you are holding an estimate, a 'non-static value' (a pending/pre-paid assumption before share paid) as a known integer(your random cash exchange montra above), a static known value. 

We understand that Share%*98% is what you should theoretically be paid.   But again.... Theory.  The path of the result is unknown to most.  Is the pool getting 2% of all mined blocks, then the rest is divvied up?  What order does it happen in?  How would the resulting estimate be a different number between those two events?

Yes.  Some logic will interfere.  It inherently does.  This is why programmers are highly paid.... because they can understand, and think on these types of levels.   But sometimes... people miss details.  They stick one calculation before the rest and it work fine in all but one or two instances.

These are called bugs.


Now if it's a real problem (not meeting 100% in all daily payouts between everything it needs to be), yes.  that is serious.  But there is no proof of a problem.    Just some symptoms with no cause or hysteresis of proof in them.

But there's a very real chance, an equal chance or possibly greater that it could just be a display problem via the code....  remember, it's pre-estimating.  I keep repeating this.  Over and over again.

But you yourself are speculating on an estimate.  Something that has always been labeled an estimate.   Just trying to say, don't discount things that are plausible.  You are guaranteed nothing until the funds are cleared and in your balance.  Period.   The investigations should keep this well in mind.

You are pointing at a calculation you do not fully understand and saying: "This result must be 20% higher". But not saying WHY through the flow of diagnosis of that calculation.    Especially after being given a very plausible and equally speculative answer to your speculation itself.

The fact that it shows a higher credit before than after on a same payout coin is a main issue to investigate.  It could be merely a display issue for all anyone knows. 

Understand how I see it?

BTW: No hard feelings meant.  Not at all.
I'm not trying to prove anybody wrong, but I am trying to decisively make this stay on track and not a poop-shoot of potentially incorrect data.   The focus is objective analysis of the estimate and exchange code.

Just because one person doesn't have the coins exchanged... doesn't mean the pool doesn't calculate the split in exchange costs between all users who have shares on that block....  unless this is a known factor... which I believe it's still unknown.

I am wondering if the sale of coins on an exchange could cause the share of the person to be less in the end because they are also splitting the conversion cost?

Makes sense for that kind of coding mistake to happen because they are trying to make everything an equal split in the end.


I think that totally makes sense why a solo mined coin to payout type can end up being less in the end.    The block reward was split after the remainder was to sold on the exchange.  Sale fees, etc..... Since value and fees are unknown till sold...

anyone else see my flow of thought?

crackfoo, I have a way to help you try and figure it out based on what the guys are piecing together...

disable a single coin port, such as sib... what was used in the example.  Perfect choice because it's a solo port, and rarely used compared to the rest.

change the port and don't advertise it.   Have only one person/wallet mine to it for one to five full payout cycles.

From there it should be easy enough to track down what's going where as far as the sql logs they speak of (I never got much into databasing, I was more interested back then on the meat of programming code).  All records would be for the same account, I would assume that the server would keep a record of the wallet that the generated coins appear in (is it static?) and it could be verified in the host coin's blockchain to verify the wallet is going empty and to where (should only be two payouts, one to wallet of miner, one to pool/sent to exchange yes?  Is there a way for you to verify the exchange wallet matches the one in the blockchain).  Just save a copy of the logs/database at that moment and you can spend more time studying a static dataset.

Also dont forget to include/count TX fees when applicable.

Also: I am wondering, does the pool's 2% go to the exchange and paid out to BTC the same as the rest of us?  or are you holding your remains in the hot-wallets that generated coins are created in and selling later on exchange?  I can't help but wonder if a code snippet in there could be changing a value that's only supposed to be read....

This came to mind... so I thought I would share.

When you actually think about what needs to happen here... its no small task... not in the slightest....

Look at the edit I made to your string.    I suggest not polling the card with ccminer if you don't plan on hashing with it  Take one more thing out of the equation....   I mean;  I see results for your 750Ti; 50 Mh... but you are putting intensity to zero?   Maybe I am confused after looking at it once more...


But I have found that some cards will take different max intensity settings between them as well.  Some have better cooling for their positioning in the casings, etc.  Lots of variables... but it looks like you are figuring out the stability issues.

Yep.  Tried every way... Pool always shows as online and it connects to mine/rent.

I discussed it with them in detail over email about 2 months before tha halving.

I've set p=3 and it still connects and sells under 3/ph.

Through emails at the time they confirmed the issue with s7 and later gear.
They said s3 and earlier worked as expected.  Don't remember s5 comment.

They suggested "flashing the antminer".  Tools.

I'd be renting my S7; but the p= flag is broken specifically on antminers; so I can't set minimum profitability to rent.

Very annoying; especially since NH could easily change the format of the string (I think it's something to do with the equal sign).....

You lose on nicehash fee.

You lose on payment tx to NH.

24hr estimates are for the previous 24hr with x hashrate;  not 24 with X plus your rental.


Many ways to loose on a rental.  If t was as easy as you think, machines would be rented 247 by the same people all tihe time earning profit.



I also agree: argon2 is crap.  I don't mine it anymore.

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...

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.

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.

Your prerogative;  although there is no problem with the amount paid.  Remember.. its an ESTIMATE done with a calculation that nobody fully understands because they did not write it.

Nothing is truly confirmed as of value until it's sold on the exchange.  End of story.  Sell price is sell price; and that's what happens when you exchange.  Just because exchange price is X;  doesn't mean that buyers are paying price X.




The real reason I am reporting this morning:

I am happy to report more stable overall hashrates on my machines by running an instance of ccminer per-device.
Still have yet to dust off the S7 and try the sha256 port again.

It's nice seeing 30+Gh of lbry on the pool.  Looks like the percentage incentive drew in a crowd.

Read the last 10 or so pages of this thread.

Also read the main site's main page about payout threshold.


You seem to have missed the obvious. As you did not meet your payout, and there's specific reasoning why balance drops before confirmed and owed.

Then apparently you misread the main page and his reply:  the web URL has changed for connecting.... its very apparent when you compare your "Can not connect" error message to the URL that is provided in the reply above....

I normally repeat this but I'm only going to say it once:  DO NOT MINE WITH A LAPTOP.

Mobile processor variants are low power.  Not designed to be run at max TDP for extended periods.  I have killed many laptops learning this and confirming my suspicion.

They are simply not designed to take that kind of load.

You are required to have a full nvidia driver as well, so if your manufacturer has an issue with their implementation, usually they never fix the driver in the end.  Keep that in mind as well.  Most M variants require a manufacturer and model specific driver because of chip lane addressing between different mobile manufacturer designs.

You would eat any profit by trying to cool the power supply and machine enough for it to maybe be reliable and last longer than a few months.

Hahahaha . Just a machine identifier...

I think it's 165w tdp.... But the cpu doesn't mine.

That address is my personal incoming addy... I usually almost right away xfer out to another wallet when confirmed.  That machine is my home PC that's online when I am home presently because I have had medical bills more important than an internet bill


I like to put a ID string at the beginning of the password for machine/miner distinction to see which locations are lagging behind others, or incase of failure and reset needed.

I have another BTC address I mine here with my main units that are in many locations (I am hosting them for people or they are hosting a location and Internet connection and power for me to abuse freely or for a small fee
Look at the TDP of the Intel L5335... 50w tdp.  I had a Dell Precision 690 with 2 of them and 24gb ECC... Upgraded to the faster more powerful x5650 3.0ghz chips after and felt the hit on my power draw (I use every watt I safely can at home because it's included free with my space rental).