This concept has also been proposed / discussed... and I totally agree, but apparently you do need to modify some software, and it shouldn't be a one-time thing, but a periodic check (like drug testing).

The definition of acceptable variance can be debated (wider window, longer time), but there's currently no mechanism to determine if some people or group of people are behaving badly.  The notion of subgrouping helps identify the bad actors.  If your "group" consistently performs below statistical expectation, then something's not right.

You could keep the payout as is, but simply start tracking groups of people for non-normal behavior... right now, everything is monitored on a total pool basis.

The question stands... how do you know if you're being attacked at a level that is not statistically acceptable (cost of business, assume some crooks always exist).

As difficulty rises, it makes it harder for the small guy to find out if his hardware is dud, especially if they participate in pools.

Given the douchery of almost EVERY mining hardware manufacturer out there, I would not be surprised if garbage is being sold.  The only people who can truly test the HW are the manufacturers.  When you manufacture silicon and assemble the chips, you have test programs that allow you to test the circuit.

You would have to be an idiot manufacturer to not test the goods.  You know which chips are stable / good, and which are bad. 

ONCE you seal up the device for sale, you put a "warranty void" sticker on it, but that prevents many hobbyists from opening it up and testing themselves (if they know the pin sequence and codes), so they operate on faith that it is good hardware.


In a completely random universe, the pools should be receiving coin proportional to their hashrate.  I have never bothered to check the math... but it shouldn't be hard to do.

Philipma... i agree with you, mostly because I proposed group statistical evaluation and probation.

Do i care if a small miner benefits from bad hardware/software?  In theory, yes, but how does one practically identify and enforce?

Well, one idea is go back to grouping the miners together, and paying out proportional to their contribution if it is outside an acceptable statistical mean.  You could manage it on a rolling "find" basis. So, for example, if a 200 Th group should find 9 blocks (on average) over a one month period, with a deviation of +/- 1 block, but your group finds 6, that would be statistically abnormal... so the group payout would be less. Likewise, if a 200 Th group finds 12 blocks, you could argue they should get more.

Over time, in the law of averages, it should even out.  But if a group is consistently underperforming, then you know you have bad actors (intentionally or not).

It is a completely different way of operating a pool. So, Dr. H needs to buy into this idea and determine whether it is worth his time. 

Okay, I concur all pools are vulnerable to block withholding attacks (currently) .. and established bad software exists, and we can debate hardware concerns pointlessly as a "consumer union" report would have to test different hardware with testcases.
 
So, given that vulnerabilities exist, do you think it is possible and worth protecting against known vulnerabilities?

Is there a statistical test to say that a miner or group of miners are behaving unusually ... I would think there is.

Do you think that "bad hardware / software" exists and that could make the pool vulnerable?  

Are pools vulnerable to abuse... that's the central question.

While I think this pool is vulnerable, the only person whose answer is valuable in this forum is Dr. H.

So, Dr. H do you think this pool is vulnerable to abuse?  And if so, what do you think should be done.  And if NOT, why do you think so?

Fair enough, your tolerance for bad "luck" may be higher than mine... and you set the rules.

But in fairness, there are no safeguards against "bad actors" ... and there should be a definition for behaving badly (or statistically improbabe).

MP left ... taking 75BTC more than contributed... and we never got to see if he would have normalized

If you walk into a casino and play the slots and every coin you put in results in a payout... the Casino would shut that slot down and check for mechanical bugs.  It is not statistically normal even thought it may be statistically possible.

Pool mining ASSUMES  all users are honest, and all users have hardware/software that are equally capable of finding a block,  and that's why pool mining works.  If you violate one of those assumptions, then you are taking advantage of the pool, intentionally or not.

So, that's the issue for me and others with respect to multipool. Multipool was reaching "my" limit of unreasonable behavior for the size of the hashrate. In a manufacturing operation, you expect a mean performance and you have upper and lower control / spec limits.  if you are drifting far from the mean, consistently, you investigate why.

We are dealing with with real costs (capex and operations), which makes the conversation more emotional because for most of us it is *our* money rather than faceless corporation money that is mining.

On Phillip's idea to assess miners by the hardware they use:

As a HW consumer and pool user, I would love that comparison, but I don't see how that can be done in practice in anonymous pools.  Moreover, the performance capability of miner is affected, as Minor_Miner points out, to hardware and software, as well as clocking conditions.

I just don't see a way of validating that users are grouping their hardware correctly.

The simplest / cleanest way of validating a user's hardware is to be able to periodically and randomly test a user's hardware / hash volume with a test case (like drug testing for athletes). A larger user should have to demo hashes proportional to their size.

The next level (but more complex) option is to group users into larger buckets (5 Th sub groups and 250 Th groups) to assure one bucket is behaving in statistically consistent ways, with randomization of the subgroups periodically to ferret out weaker players.  This idea will go to address the viability of the hardware as we climb the difficulty curve.  It is conceivable that hardware that works at lower difficulties breaks at upper difficulties simply by the way the HW/SW combo hashes.  We are looking for unexpected / forseen issues with hardware.

I expect the latter problem to go away as the payouts diminish with time, and the power hungry machines start to lose money on an operational (electricity cost) basis.  The more mature stuff *should* be better tested.

Been lurking awhile... but the whole multipool saga provokes me to speak up.

A constructive discussion on how the pool maintains integrity is needed.  Bad or incompetent actors are out there, and we need to have a way of screening for them.  To not have a process or method in place is a disservice to the honest actors on this pool.

Pool operation rests on a couple of key premises, i think:

• 1.  all hardware is capable of finding a block or doing work to confirm a block
• 2.  all users contribute their finds to the pool
• 3.  the pool fairly tracks the hash contribution on an appropriate time basis

Are there more operating assumptions?

First, how do we validate the first two premises?  To me, over a given period of time, for a given integrated hash contribution, you should be able to calculate the expected block finds to a reasonable standard (a confidence interval or t-test).

To Entropy's point, a 95% confidence interval is a pretty well-established standard for making significant decisions.  What is the board's expectation.

I think we all want to have confidence our hardware is operating in a statistically normal way.  Bad hardware is bad for all of us, just like a bad member is bad for all of us.

So, second, how do encourage new contributors with confidence that we are not being screwed?

One idea is to first group our hashers into subgroups of 200 +/- 10% Th (terahash).  We could then determine, over a period of time, whether any subgroup is statistically deviant.  You could even randomize the groups to try and isolate weak (statistically improbable) hashers.

For newer members, we might want to consider putting them in a probationary phase (as part of a newbie group), with their payouts going to escrow until the meet a certain confidence threshold.

Ideally, we should be able to just straight-up test the member hardware with test cases, especially from the higher difficulty regime.

I think Bitminter is a solid group.  As far as I can tell, I think the contributions have been largely proportional to the member hashrates, and our hash size relative to the global community.  We may in fact be doing a little better than average recently (excluding multipool)... which begs the question - why?