[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[14er]

With that said Multipool has been mining for about the same time with almost 10x my hash power so how can this be right?

If you and a friend walk into a casino, your friend bets 100 USD and wins 1 USD, you bet 1 USD and win 100 USD. How can this be right?

I don't think the casino would even bother to explain it. They would look at you for a moment, and decide you have had enough to drink.

It's random. This is why you mine in a pool.

Some users get a lot more pay than the blocks they find, some get a lot less. This is how pools work.

95% CDF doesn't mean there is 95% probability that the person is a scammer. If you mine long enough, it will happen to you. It doesn't mean you are a scammer. 5% of the time your luck is expected to be that bad.

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.

[organofcorti]

You seem to be obsessed with having a pedantic debate on statistics.  I have absolutely no interest in that.  If you want to CONSTRUCTIVELY discuss how public pools can be defended in an environment where people are actively trying to cheat them I would be very interested in seeing what you think.

Bitcoin mining *is* statistics. If you don't understand them, you don't understand mining.

As I said, pedantic.

And with a Ph.D in engineering and over a decade in semiconductors I can assure you I understand the statistics just fine.

I look forward to your analysis of what actions a pool should take to defend against exploitation by miners either intentionally withholding block solutions or operating defective hardware.

All I have attempted to do here is explain the what multipool experienced was not unusual. My mistake lay in thinking that you didn't understand that. However from your last post, I see that you claim to understand the stochastic nature of pooled mining rewards, but you find it pedantic. You understand, but you don't care.

Well, that's where I get off. If you understand that it was not particularly poor luck, then I have nothing to explain to you. It does however leave me wondering why anyone - when discussing the topic of bad luck in bitcoin pool mining - should care about the opinion of someone who doesn't think the process is important?

[Grayson5]

Doc (or someone who can confirm / correct my assumptions),

Now that I have a decent amount of miners hashing I think it might be worth activating some additional perks but I want to make sure I understand the math correctly.

I currently have automatic donations for BTC and NMC on (1.5%BTC + 1%)

and prepay BTC & NMC @ 1.5%.

Sticking with just BTC and using 0.1 as the expected amount paid per block on the account page is the following correct....?

For each block found I would receive .096 BTC's calculated as  0.1 minus 1.5% (.0015) for automatic donations minus another (.001) for the fee minus another 1.5% (.0015) for the prepay BTC.

Additionally, if I activiate the team effort perk at .50% BTC than is would cost another (.0005) BTC each block.  And the non-stop mining perk would cost .0001 BTC each block.

Is the math correct here or am I off some decimal places?

Finally, it is more cost effective to just actiive the Pro Minter perk if I am interested in most of the perks (except many the easy mode - which I confess I am not sure I understand completely).

Thanks for any help!

First time I've posted a question on the forum and not received any answers.... 

Guess the multipool issues has everyone fired up.

Can anyone confirm the calcs above?

[philipma1957]

You seem to be obsessed with having a pedantic debate on statistics.  I have absolutely no interest in that.  If you want to CONSTRUCTIVELY discuss how public pools can be defended in an environment where people are actively trying to cheat them I would be very interested in seeing what you think.

Bitcoin mining *is* statistics. If you don't understand them, you don't understand mining.

As I said, pedantic.

And with a Ph.D in engineering and over a decade in semiconductors I can assure you I understand the statistics just fine.

I look forward to your analysis of what actions a pool should take to defend against exploitation by miners either intentionally withholding block solutions or operating defective hardware.

All I have attempted to do here is explain the what multipool experienced was not unusual. My mistake lay in thinking that you didn't understand that. However from your last post, I see that you claim to understand the stochastic nature of pooled mining rewards, but you find it pedantic. You understand, but you don't care.

Well, that's where I get off. If you understand that it was not particularly poor luck, then I have nothing to explain to you. I does however leave me wondering why anyone - when discussing the topic of bad luck in bitcoin pool mining - should care about the opinion of someone who doesn't think the process is important?

    Well while you and I may share a love of numbers and or how numbers are used in statistics many people here are earning their living via mining.
     It has become apparent that pools have an Achilles heel and finding good ways to protect the heel are needed. We do not need to fight about definitions of good luck, bad luck ,random activity. We need to  come up with plans to help guard against all the pools Achilles's heel that has been found. 

I am not sure if right now everyone even agrees that  this Achilles's Heel is factual and indeed does exist.  I agree multipool was given a very short lease. I agree that the math did not show their bad luck to be extraordinary. On the order of 10,000 to 1 would be really bad it was not at that level. Or even close to that level. It was under 100 to 1. 

   The problem is they were close to 16% of the entire pool and no safe guard is in place.  1 month with 1 block would be less then 1000 to 1 and that does happen every once in a while.  But with no deterrent no safeguard  attracting of a real villain that knows we sit  wide open has to exist and in fact be higher then if we have a safeguard or deterrent.

  So other then setting the entire pool to  solo mining 2 hours of every day or 1 hour of every day or 3 hours of every day what would you suggest?

 Also do you agree that for the time period that the pool is in solo mode  this danger would not occur?

[DrHaribo]

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.

Problem is that this was not particularly bad luck. You can't call it consistent either, because they mined for a very short time.

Complaints started when their mining was at a CDF of about 70% which is just silly.

Even at 95% CDF you may think this is really rare, but it's not. If you crashed your car 1 out of 20 times you drove, would you still say that's so rare you would never expect it to happen?

Can anyone confirm the calcs above?

If your percentage of the hashpower in the pool meant your part of a block was 0.1 BTC and you got 0.096 that would mean you paid 4% in fees and donations.

If you have 1% fee + 3% donations, you can reduce the donations and keep the same perks by activating the pro minter perk. With the pro minter perk, that's the only one you need to cover with donations - as long as it is on the other perks are free to activate without additional donations.

So other then setting the entire pool to  solo mining 2 hours of every day or 1 hour of every day or 3 hours of every day what would you suggest?

I'd suggest we finally do the hardfork on bitcoin that has been suggested long ago, which would make block withholding impossible.

[philipma1957]

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.

Problem is that this was not particularly bad luck. You can't call it consistent either, because they mined for a very short time.

Complaints started when their mining was at a CDF of about 70% which is just silly.

Even at 95% CDF you may think this is really rare, but it's not. If you crashed your car 1 out of 20 times you drove, would you still say that's so rare you would never expect it to happen?

Can anyone confirm the calcs above?

If your percentage of the hashpower in the pool meant your part of a block was 0.1 BTC and you got 0.096 that would mean you paid 4% in fees and donations.

If you have 1% fee + 3% donations, you can reduce the donations and keep the same perks by activating the pro minter perk. With the pro minter perk, that's the only one you need to cover with donations - as long as it is on the other perks are free to activate without additional donations.

So other then setting the entire pool to  solo mining 2 hours of every day or 1 hour of every day or 3 hours of every day what would you suggest?

I'd suggest we finally do the hardfork on bitcoin that has been suggested long ago, which would make block withholding impossible.

 

thanks so there is something better then my idea in your opinion the  hard fork .

  because frankly   we need to do something and to continue to allow block withholding without a deterrent is not acceptable.

[Minor Miner]

What may seem silly to you, is not to me.   But then our rewards and costs are not exactly aligned with you as the operator of the pool.    The cost of free riding is far less to you than to the miners.   For some, it is the difference between profit and loss.
You and ooc are looking at this from the perspective that each pool is a 'fair deck'  whereas I firmly believe there are miners that do not work.  
That difference likely makes me shoot someone who jumps the wall to my house before he robs me and before he pulls a knife and kills me.  OOC would state "there is still a 1 in 1000 chance that this person is in your home by chance and picked up your belongings by chance and that the blood coming from the stab wound was not from his knife".   I overreact, he under reacts.     BTCGuild is a GREAT example of this.   Constantly I (and others) were told we were being stupid and it was bad luck and this happens "all the time" (although all the time was like 3 years ago wasn't it?).    What happened?   Who was correct?   
Do I think multipool was a bad actor?   Not likely.  Do I think something could be wrong with his code or his users equipment?  Possibly.   Do I get more suspicious by his lashing out at people from the very beginning?   Yes.   His arrogant denials?   Yes.  His unwillness to prove us wrong by hashing until his luck normalized so he can satisfy his ego to call me an idiot?   Very suspicious.  
Now you know where we stand and our tolerance for risk and that the tolerance level is based the fact there is some unknown amount of bad machines out there.   It is your pool, you are free to make the rules.   

[GigaBit]

Oh so, it wasn't just me then, I thought there was an attack so I scrammed during the third red until things got sorted out by the experts.

I knew something was adrift when I noticed multipool with up to 80TH/s fluctuations when Koi's rarely went under 200TH/s.

And then when Koi was stable at 220 TH/s and MP was down to like 170TH/s, jumping all over; like the problem I WAS having before.

One of these things is not like the other lol   

However, last time I spoke about fluctuation in hashrate was pretty much called a fool; I stand corrected. -> http://screencast.com/t/l0uwGvoFh1z (After Plugging 1TH/s & Correct diff)

My problem was worker difficulty I had not set manually for my miners, thinking it was automatically done by the pool.

Well, having done so, I was consistently averaging OVER 1TH/s average rate until the recent erratic behavior from my miners with BitMinter.

I can only assume multipool does not have the ability to set all his miner's difficulties or is too lazy to do so.

As one said, Koi took a lot of time to switch over but done so in a permanent way, not in a testing way... so maybe MP wasn't giving a fair chance?

Either way, more coin for the little guys

Sounds like someone did a bad investment and wants everyone else to pay for it...  typical wall street.

I mean if setting the difficulty manually and NOT use the easy mining perk did it for me in a big way, I am sure it could a similar difference for others.

IF anything, it should be on the worker settings page:

Set Worker Difficulty According to Manufacturer Specs or Risk Running Into Speed Issues.

I am sure many new miners disregard this fact too; if it is forewarned, then anyone who disregarded the warning can only blame themselves.

Inefficiency OCD's a bitch....

Peace Out

[14er]

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.

Problem is that this was not particularly bad luck. You can't call it consistent either, because they mined for a very short time.

Complaints started when their mining was at a CDF of about 70% which is just silly.

Even at 95% CDF you may think this is really rare, but it's not. If you crashed your car 1 out of 20 times you drove, would you still say that's so rare you would never expect it to happen?

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

[ichtus27]

I noticed to that i had to set the worker difficulty low and have that perk on. Did not check it out more than that.
Thinking of it, it is stupid to set it low and have that perk on so you can set it high .

Changed it and thanx for the wake up call.

And yes both u1-u2 and s1 jumped all over the place here from 0 to 320 or so, i have here 190,12hash.. so..

[philipma1957]

What may seem silly to you, is not to me.   But then our rewards and costs are not exactly aligned with you as the operator of the pool.    The cost of free riding is far less to you than to the miners.   For some, it is the difference between profit and loss.
You and ooc are looking at this from the perspective that each pool is a 'fair deck'  whereas I firmly believe there are miners that do not work.  
That difference likely makes me shoot someone who jumps the wall to my house before he robs me and before he pulls a knife and kills me.  OOC would state "there is still a 1 in 1000 chance that this person is in your home by chance and picked up your belongings by chance and that the blood coming from the stab wound was not from his knife".   I overreact, he under reacts.     BTCGuild is a GREAT example of this.   Constantly I (and others) were told we were being stupid and it was bad luck and this happens "all the time" (although all the time was like 3 years ago wasn't it?).    What happened?   Who was correct?  
Do I think multipool was a bad actor?   Not likely.  Do I think something could be wrong with his code or his users equipment?  Possibly.   Do I get more suspicious by his lashing out at people from the very beginning?   Yes.   His arrogant denials?   Yes.  His unwillness to prove us wrong by hashing until his luck normalized so he can satisfy his ego to call me an idiot?   Very suspicious.  
Now you know where we stand and our tolerance for risk and that the tolerance level is based the fact there is some unknown amount of bad machines out there.   It is your pool, you are free to make the rules.  

well ddos a fact no one argues.
 
bad luck miners seem to exist.

 I am a small miner in fact I have more mining at ltc then I do at btc.

My ltc gear makes blocks not a lot but it does make blocks.

  I have not made a btc block in a year  as I have not grown like the network did.  Back in 2012 I earned a coin a day and made a block about 1 time a month.  All gpu based.

My last block was with an asic miner be usb stick in very early sept 2013.

  my btc hash is 1.6th or a block every 14 months.

my ltc hash is 26mh or a block every   23 days.

    Right now I am more inclined to stick with my gridseed blades  and mine ltc why  ?  I know they make blocks.  For now I can keep up with the diff rate.

  
 You can buy 10 gridseed blades  for 5000 usd  and burn only 800-850 watts  hash at 52mh and make a block every 12 days.
 
 You need to buy 56 s-2's   or about 84000 usd and burn 56000 watts  hash at 56th  and make a block every 12 days.

 I have the money to buy the gridseed and run them so that I can see blocks made.  I am doing it right now.


 I am not going to be able to do this with BTC  so I need a pool.
 I would like to know it is a good pool.
 I would like to know certain gear works well.  
 Say an s-1 or an s-2 or an s-3.


Or another way If I have to solo mine LTC I already know my gridseeds make blocks.

[Entropy-uc]

Problem is that this was not particularly bad luck. You can't call it consistent either, because they mined for a very short time.

Complaints started when their mining was at a CDF of about 70% which is just silly.

Even at 95% CDF you may think this is really rare, but it's not. If you crashed your car 1 out of 20 times you drove, would you still say that's so rare you would never expect it to happen?

I'd suggest we finally do the hardfork on bitcoin that has been suggested long ago, which would make block withholding impossible.

Concerns were raised because of:
 - a history of other pools being abused
 - the very large size of the user, with no pedigree of success on other pools
 - the risk of others using the pass through to veil their exploitation of the pool
 - the opaque means that flound makes a profit with this venture
 - below expected returns from multipool

The combination of those items make it very likely that users were being exploited by multipool.  It's called Bayesian analysis.  And at 70%, with the additional data it was perfectly rational to start asking questions.

With PPLNS your incentives are not aligned with your users.  You lose nothing when the pool is being exploited.  You collect your cut regardless and just distribute the rewards unfairly.  That means users like me have to be watching carefully.  Given his response, I think it is very likely that Flound knows, or at least suspects that some of his users are exploiting the pool.  I have to wonder how far you would have allowed things to progress.

A hard fork of bitcoin is out of the question, for the same reasons that countries almost never rewrite their constitutions.  Too many competing interests would attempt to force their interests into the hard fork, and consensus would be impossible to reach.  We are already past the point where a super majority favorable to public pools could even be formed.

A revision to stratum is possible, and I'm quite surprised it isn't being actively driven by pool operators.

[philipma1957]

Problem is that this was not particularly bad luck. You can't call it consistent either, because they mined for a very short time.

Complaints started when their mining was at a CDF of about 70% which is just silly.

Even at 95% CDF you may think this is really rare, but it's not. If you crashed your car 1 out of 20 times you drove, would you still say that's so rare you would never expect it to happen?

I'd suggest we finally do the hardfork on bitcoin that has been suggested long ago, which would make block withholding impossible.

Concerns were raised because of:
 - a history of other pools being abused
 - the very large size of the user, with no pedigree of success on other pools
 - the risk of others using the pass through to veil their exploitation of the pool
 - the opaque means that flound makes a profit with this venture
 - below expected returns from multipool

The combination of those items make it very likely that users were being exploited by multipool.  It's called Bayesian analysis.  And at 70%, with the additional data it was perfectly rational to start asking questions.

With PPLNS your incentives are not aligned with your users.  You lose nothing when the pool is being exploited.  You collect your cut regardless and just distribute the rewards unfairly.  That means users like me have to be watching carefully.  Given his response, I think it is very likely that Flound knows, or at least suspects that some of his users are exploiting the pool.  I have to wonder how far you would have allowed things to progress.

A hard fork of bitcoin is out of the question, for the same reasons that countries almost never rewrite their constitutions.  Too many competing interests would attempt to force their interests into the hard fork, and consensus would be impossible to reach.  We are already past the point where a super majority favorable to public pools could even be formed.

A revision to stratum is possible, and I'm quite surprised it isn't being actively driven by pool operators.

well the problem for a midrange player like me 10k in gear 500 usd power bill is pretty simple.  I can stay in BTC pools that are not addressing the bad luck, bad gear, bad software issue.  Knowing that solo mining is not practical in the btc world for me.    So I could  slide over to alt coins with gear that I know works and push comes to shove i could solo mine. any coin that grid seed blades work on.

  I have 4k plus in grid seed gear burning under 600 watts.
I have 1k gear in house for btc gear burning  800 watts.
I have a 1th dragon miner hosted in china costing 180 usd a month to host.

I have more then 10btc to hold or invest.  So I have various ways to go.  I really want to continue to mine BTC but

LTC + alt coins have grown for me while I have shrunk btc due to the pool issue I see.

 Frankly pool ops need to get together on this one way or the other or more of us may drift into alt coins since we won't be so small a fish so to speak.

MY skill set is not coding so if some says stratum  revision works lets do it.  I know quite a bit about quite a lot of things in life and i can say doing nothing at all is not the best idea for pool ops.

[DevonMiner]

A revision to stratum is possible, and I'm quite surprised it isn't being actively driven by pool operators.

As you say, a hard fork is not practical, however if a revision to stratum is possible that agrees with the masses, it sounds interesting.

Not saying I have a huge amount of knowledge in these areas, but is this reasonably possible?

[cenicsoft]

Concerns were raised because of:

 - the very large size of the user, with no pedigree of success on other pools

I've used Multipool's services for ALT coins and it seemed to be on the up and up. Blocks were solved and payments made. The above concern regarding BTC was my main concern and that's why I mentioned it. I specifically asked how many blocks they solved at other pools and it was mentioned that they didn't know because the other pools didn't report that information.

I don't think their users' gear is bad or that they are intentionally withholding blocks. It may be most likely with their proxying of hash power. It we take a look at that for a minute, is it possible that a block could be solved, but due to timing of sending the result to the network, it was being preempted by another pool solving the block? Or would we simple see an increase in orphaned or invalid blocks?

Some time ago, I thought someone mentioned that by solo mining, if you didn't have a priority connection to relay found blocks, even though you might find blocks, you'd have a better chance getting them accepted as valid by the network by mining with a larger pool.

Any clarity on the above is appreciated.

[Entropy-uc]

Concerns were raised because of:

 - the very large size of the user, with no pedigree of success on other pools

I've used Multipool's services for ALT coins and it seemed to be on the up and up. Blocks were solved and payments made. The above concern regarding BTC was my main concern and that's why I mentioned it. I specifically asked how many blocks they solved at other pools and it was mentioned that they didn't know because the other pools didn't report that information.

I don't think their users' gear is bad or that they are intentionally withholding blocks. It may be most likely with their proxying of hash power. It we take a look at that for a minute, is it possible that a block could be solved, but due to timing of sending the result to the network, it was being preempted by another pool solving the block? Or would we simple see an increase in orphaned or invalid blocks?

Some time ago, I thought someone mentioned that by solo mining, if you didn't have a priority connection to relay found blocks, even though you might find blocks, you'd have a better chance getting them accepted as valid by the network by mining with a larger pool.

Any clarity on the above is appreciated.

Firstly, I don't know of any pool that does not track how many blocks you solve. The information is also available on the client side if you are running a native cgminer or bfgminer.

If you are solo mining, you need to be confident that your block solutions are efficiently distributed to the network or your risk orphans.  You also need prompt notification of new blocks to maximize efficiency of your workers.

[jjdub7]

Another question I've been wondering and hoping someone with a more technical background might be able to answer for me -

When individuals in the pool solve pieces of work, how long do those valid pieces of work stay in queue to try and create a block?  Or does only the piece of work that solves a block really matter?

[organofcorti]

Another question I've been wondering and hoping someone with a more technical background might be able to answer for me -

When individuals in the pool solve pieces of work, how long do those valid pieces of work stay in queue to try and create a block?  Or does only the piece of work that solves a block really matter?

Only the work that solves the block matters - the rest of the work you submit just proves you're trying to solve a block, and how much effort you're able to put toward that work.

[Fefox]

Fefox, how in the mean time is it with you, still your same speed. Still not having the power supplies that you needed.
It was the power supplies that you where waiting for wasn't it??


greatings and luck 

Still waiting for a power upgrade, will have 1Mw of power available soon. then look out!

[jjdub7]

Another question I've been wondering and hoping someone with a more technical background might be able to answer for me -

When individuals in the pool solve pieces of work, how long do those valid pieces of work stay in queue to try and create a block?  Or does only the piece of work that solves a block really matter?

Only the work that solves the block matters - the rest of the work you submit just proves you're trying to solve a block, and how much effort you're able to put toward that work.

Got it - that's what I thought.  Its literally just trying to bruteforce a header, right?