Laurentia Pool - BAD risk for miners

[kano]

Not here to pour fuel on the fire but are you sure about that? Does that mean S17e and all other miners can be unlocked (to UC/OC) without editing bmminer/cgminer?

I made no comment about what can and cannot be unlocked or how to do it. I merely commented about that at one time I think he posted a web patch, not a full firmware with cgminer/bminer in it.

[philipma1957]

Well I am trying to get better choices for owners of bitmain gear.

I am not interested in turning profits from this t17e mod.

 I have been letting thierry4wd access my 2 t17e units on a separate router/internet service  that we maintain as back up and as a screener for virus filled gear.

At the moment he has been able to alter voltage settings from 1760mv to 1680mv.  which really helps my t17e gear.

This would benefit all miners owning this locked gear. My goal is to help anyone with a locked t17e not burn up their gear.

I also know that if we were to do this and agree as a group of pools and miners it puts pressure on bitmain to allow or at least make better firmware.

The s9 the s9i the s9j firmware from summer 2019 is decent and allows for lowering your miners temps.

So far my testing on the one unlocked t17e is showing lower temps.

The mod is allowing only lower volts at stock freq.

Every pool owner would stand a chance to benefit if miners have better gear.

A t17e using 200 watts less but hashing at same rate = win win

[Artemis3]

Has it found a block on the main BTC chain yet? I keep asking the dev's but they ignore me, I'd fucking love to run it, but its a big risk for me if I don't know that it will find a block or not.

Someone show me somewhere where its found a block, I'd like to see the miner status GUI showing a block found, the difficulty it found the block at and then the corresponding block info at the pool where it was found, preferably a reputable pool.

Be nice if there was more than one.

Here you go: https://bitcointalk.org/index.php?topic=5036844.msg55047651#msg55047651

Hope this satisfies your request.

[kano]

Has it found a block on the main BTC chain yet? I keep asking the dev's but they ignore me, I'd fucking love to run it, but its a big risk for me if I don't know that it will find a block or not.

Someone show me somewhere where its found a block, I'd like to see the miner status GUI showing a block found, the difficulty it found the block at and then the corresponding block info at the pool where it was found, preferably a reputable pool.

Be nice if there was more than one.

Here you go: https://bitcointalk.org/index.php?topic=5036844.msg55047651#msg55047651

Hope this satisfies your request.

Lulz it's missing the information that proves it.
Full screen shot or it didn't happen.
Edit: and preferably upload it somewhere where you don't get adverts and browser hacks for porn ...

[chillfactr]

It is missing alot of information to prove that it was even a btc block found.  put a full page screen shot and blur the private info if needed

[minefarmbuy]

Did you want to lock the thread now? Otherwise I'd recommend to return to shitting on our pool service.

[NotFuzzyWarm]

Did you want to lock the thread now? Otherwise I'd recommend to return to shitting on our pool service.

Or better yet, get the thread back on-topic to address the heart of the matter: Namely the fact that ckpool by itself has near zero provisions for recording performance of the pool and miners attached to it. To me at least, *That* is the main concern and reason for this thread.

One has to remember that is was written to run -ck's solo pool and for a solo pool all that is needed is recording a users current hash rate, payout address and if they found a block. -ck has and will never change that. That is why the 'records' are scads of tiny text files. However, the data IS available there and can be extracted if one decides to take advantage of it.

Once ckpool started being used to run -ck's now defunct shared rewards pool, a huge part of the feud between -ck and Kano dealt with Kano insisting on putting a database (KDB) behind it to record and verify everything going on including values for each and every share sent out and received. That database is the reason Kano was able to analyze performance of rentals to see that (at the time) they were submitting shares to his pool that were far lower diff than statistics said they should be which is what led to rentals being banned. It is also how he was able to discern that eBangs early miners were crap (and subsequently banned as well).

How much is -ck against incorporating a database? Well, in addition to the fixes he implemented, the last changes he did to ckpool also intentionally and specifically locks out using it with KDB. No idea if it also breaks links to using other DB's. Of course since Kano wrote a lot of it (ckpool) he had no problem getting around those barriers As to why -ck feels that a proper database is not needed, NFI- ask him.

Oh, and if ya did not know it already - Kanopool uses a modified ckpool as its front end which goes to prove that any 'risk' to a pool using it can be mitigated...

[mikeywith]

Kano was able to analyze performance of rentals to see that (at the time) they were submitting shares to his pool that were far lower diff than statistics said they should be which led to rentals being banned.

Ok so assuming what Kano claims is correct, does this mean every other pool that allows rental hashrate (almost all of them) lack the skills or don't have a KDB to keep records of all of the information needed to protect themselves? the pools that will suffer the most from this issue would be PPS pools, they have way more reasons to do that than Kano, yet, almost nobody does that but him, which means whatever he thinks he figured out was wrong unless Kano is smarter and have better resources than all those multi-billion $ pools, but even then you would at least expect these pools to close down when they end up paying for shares that were programmed to not find blocks.

[NotFuzzyWarm]

Ok so assuming what Kano claims is correct, does this mean every other pool that allows rental hashrate (almost all of them) lack the skills or don't have a KDB to keep records of all of the information needed to protect themselves?

Well, for a start, how many provide in-depth per worker stats to their users?
 Seriously. It's been many-a-year since I last dabbled with other pools but AFAIK few to none have decent stats available to the user. Considering that generating tailored reports is one of the things  DB's are made for, lack of said stats strongly suggest the lack of a comprehensive back-end database.

Kano has records of every connection, miner type, and share sent/received going back to the very 1st miner the pool connected to. That very deep DB is what allows him to do meaningful statistics and re-run the results when things don't seem quite right - like what led to the rentals ban.

I would hope that other pools DO have something monitoring their assets but are just too lazy to share it. Again, NFI. The Slush kerfuffle a few years back is a rather uncomfortable  indication of how some pools and their operators do things...

I trust that since running a pool is a financial enterprise, you feel it should be ran as such right? To me that means that if performance data is available one should record and use it to make sure operations are running as expected.

Can I add that in all fairness to MFB and Laurentia pool we should move this particular topic of discussion (other pools monitoring practices) to the Kanopool thread or elsewhere? I have nothing against them and it's not cool to keep bumping this one w/o sticking to the point I mentioned above.

edit:created a new thread aimed at this exact topic regarding back-ends and worker stats available to users of the various pools out there

[kano]

LOL - my post deleted from the other thread a short while ago:

I stated a little while back that the linked thread isn't where we'd like the record of inquiry for our service and people can and could post here. I can't say I'll monitor what is said there but if there's something I do see and can address I may.

-ck and I have had discussions on fw a few times. We've been lucky enough for users to have tested a few generations of asics, custom fws, hosted units, and rentals on the pool.

One of the reasons he shut down the derp ckpool but still runs solo was that some firmware will NOT work with a coinbase payout.
Your only fix for that is to remove the coinbase payout.
Coinbase payout is a bad idea to start with due to the reasons I've already posted and you've ignored.
Ignoring something coz you don't understand it is a very bad idea (like a lot of your white paper)

[minefarmbuy]

The appropriate scenario is to ask why we prefer to retain coinbase payout, not assume ignorance in retaining it.

[kano]

The appropriate scenario is to ask why we prefer to retain coinbase payout, not assume ignorance in retaining it.

Most of your white paper is based on ignorance due either someone telling you false information, or you being unable to understand what they said.
I do know a heck of a lot more more about Bitcoin and programming and server management than -ck and have on occasion told him to do things properly that he has ignored.

[minefarmbuy]

The Kano pump thread continues.

[kano]

...
LP is able to monitor poor acting fw as their share quality would be horrendous and hr is often intermittent at best. Herp would be terrible and luck as displayed would be low overtime. Easy to weed out in conjunction with their reward would be extremely low at best making it worthless for the miner to use fw like this maliciously on our pool or if not malicious the miner would be able recover by flashing stock or quality fw to continue mining if compatible. Worst case if the miner is unresponsive to adjustment we'd simply block them and with a low reward would leave the rest of the pool relatively unaffected hashing through an entire diff adj.

Part of our pw protected server is to ensure miners are aware of incompatibilities prior to entrance, can test their equipment or in this case software. With a limited user base we can easily monitor this front and backend in collaboration in -ck.
...

Alas you are again making claims that are either lies being told to you by someone else, or fabrications on your part.

This rubbish you posted is based on the false assumption that because the reward system,
that has the ridiculously named and implemented herp derp system (aside "herp derp" means stupid accident: https://www.dictionary.com/e/memes/herp-derp/ )
where higher diff shares are rewarded more i.e. smaller miners get MUCH higher reward variance vs larger miners on the same pool,
that somehow this very tiny tiny fraction of a percentage of shares that will produce this effect you are talking about will make it easy to identify mining problems?

No, the fact of the matter is that there is NO statistical analysis of the shares in your ckpool.
None, Nada, Nothing, Zero.

[minefarmbuy]

Fear, uncertainty, and doubt.

I’d imagine lower hr would as well. Then reward will have less variance on our server with a locked in hr per diffadj specifically with well operating  equipment.

Ive seen poor fw in action and imagine you have as well. It was easy to determine within five to ten minutes of mining seeing equipment struggle to produce shares and  extreme variance at 50+Th/s than a r606 at 900 gh/s.

But you know what’s best for everyone, so I imagine we’ll hear more about your greatness soon so we don’t forget.

[kano]

Fear, uncertainty, and doubt.

I’d imagine lower hr would as well. Then reward will have less variance on our server with a locked in hr per diffadj specifically with well operating  equipment.

Ive seen poor fw in action and imagine you have as well. It was easy to determine within five to ten minutes of mining seeing equipment struggle to produce shares and  extreme variance at 50+Th/s than a r606 at 900 gh/s.

But you know what’s best for everyone, so I imagine we’ll hear more about your greatness soon so we don’t forget.

"I know a specific case that shows wide ranges in hash rate shown on the pool"
Those numbers you have stated are more likely to be bugs in ckpool than a miner.

Typical response from you. Ignorance is bliss.

Alas for any future miners considering or having so called 'Commitments', that ignorance is indeed a BAD risk

Laurentia Pool - BAD risk for miners

[minefarmbuy]

No pool side variance is about +/-1% for well operating equipment. Everything overtime reports extremely accurate. Guess again fren.

[kano]

No pool side variance is about +/-1% for well operating equipment. Everything overtime reports extremely accurate. Guess again fren.

Pool side variance on a shift of 50 minutes is about +/- 7%
Statistical fact.

Read about CDF here: https://kano.is/index.php?k=poisson
Shares are also a CDF distribution. Just a lot more of them that (obviously) makes the variance lower.
Oh you didn't know that? -ck probably doesn't either.

Reality please, no idea where you got that 1% number from, but since your ckpool pool has no shifts, no collection of groups of data, just a stupidly named herp derp as at some specific point of time, written to a text file every so often, you clearly have no idea what you are talking about.

If you claim that your 5min/hourly hash rate numbers are always within +/-1% of the miner's hash rate, then you are bull shitting people.

[minefarmbuy]

I don’t recall specifying a time frame. Again you don’t pose any queries just assume.

For everyone else 1% is a median based on the data I have specifically from analysis of front end which is what I manage. From my own equipment and others, who have compatible factory fw, asicboost, and operate within advertised spec. From 1hr and longer.

But whatever narrative you’d like push here is gospel. I do like bullshit but mostly over beer and good food, not about the service I provide.

Funny thing is if anyone thinks Kano has their best interests at heart here they’re mistaken. This all about ck, kano’s ego, the failing of Kano pool, and some weird, chaotic, flailing attempt to kill our project here because of all of the above.

[kano]

I don’t recall specifying a time frame. Again you don’t pose any queries just assume.

For everyone else 1% is a median based on the data I have specifically from analysis of front end which is what I manage. From my own equipment and others, who have compatible factory fw, asicboost, and operate within advertised spec. From 1hr and longer.

But whatever narrative you’d like push here is gospel. I do like bullshit but mostly over beer and good food, not about the service I provide.

Funny thing is if anyone thinks Kano has their best interests at heart here they’re mistaken. This all about ck, kano’s ego, the failing of Kano pool, and some weird, chaotic, flailing attempt to kill our project here because of all of the above.

Again ignoring facts and as usual trying to divert this away to being about KanoPool.
Simply because you have no idea of the details about what you are discussing.
You are just reporting numbers displayed or told to you and words told to you by someone else.
A pool run by a marketing guy - oh dear - the thread title just gets more and more correct every day.
Learn a little: https://kano.is/index.php?k=workdiff

Not even a miner knows it's hash rate.
It must calculate it based on shares submitted since the advent of AsicBoost, though the drivers have already been doing this for a long time anyway, assuming that each share generated represents the difficulty of the request to the miner hardware.
The same way that a pool has to calculate it, as an estimate based on shares submitted, since a pool will never know how many hashes a miner has actually done.

Shares have a Poisson distribution just like blocks and have the same CDF properties.
Thus hash rate has variance, and it's not 1%

Ckpool itself also does not show an accurate hash rate, that's also a fact.
At the pool level, after a long period of running (usually a month or so) it over reports the pool hash rate.
This is blatantly obvious when you group shares into shifts and have a shift by shift calculation of the pool hash rate.
The average of those shifts, over time, will be lower than the ckpool displayed value.
The ckpool displayed value is a decaying function based on the 'current' value, not based on a set from history.
It's also not the values it claims to be 5 min/1 hr, since the decay takes longer than that to reach zero - e.g. a miner doing no mining for the past hour 'should' have a 1 hour hash rate of 0 but it usually doesn't