[ANN] profit switching auto-exchanging pool - www.middlecoin.com

[Agrippa]

Anytime I said "half a share" I am speaking in a probability sense, not a literal sense.

That's there problem. There is no "halfway" in the probability sense. That's exactly what the gambler's fallacy is all about. If you're throwing dice and trying to roll a six and the first three aren't six, it's incorrect to say "Well gee, it's a 1/6 chance and I've thrown it 3 times, so I must be halfway there!" The harsh reality is you've accomplished nothing. No amount of missed rolls bring you any closer to what you're after. You could roll one hundred non-sixes in a row and the 101st roll would still be a 1/6 chance; no more likely then the first roll.  A die is just a piece of wood or plastic, the way physics behaves on it remains the same.

[1714180124]

1714180124

[1714180124]

1714180124

[1714180124]

1714180124

[1714180124]

1714180124

[mueslo]

That's there problem. There is no "halfway" in the probability sense. That's exactly what the gambler's fallacy is all about. If you're throwing dice and trying to roll a six and the first three aren't six, it's incorrect to say "Well gee, it's a 1/6 chance and I've thrown it 3 times, so I must be halfway there!" The harsh reality is you've accomplished nothing. No amount of missed rolls bring you any closer to what you're after. You could roll one hundred non-sixes in a row and the 101st roll would still be a 1/6 chance; no more likely then the first roll.  A die is just a piece of wood or plastic, the way physics behaves on it remains the same.

Well-said. At first I also thought the difficulty would change things, but that's because I didn't really know how the difficulty worked, I thought it was a bundle of diff-1 shares. I'm not quite sure  where Liquidfire's problem in understanding lies, I suspect it's the statistics side.

[cverity]

Anytime I said "half a share" I am speaking in a probability sense, not a literal sense.

That's there problem. There is no "halfway" in the probability sense. That's exactly what the gambler's fallacy is all about. If you're throwing dice and trying to roll a six and the first three aren't six, it's incorrect to say "Well gee, it's a 1/6 chance and I've thrown it 3 times, so I must be halfway there!" The harsh reality is you've accomplished nothing. No amount of missed rolls bring you any closer to what you're after. You could roll one hundred non-sixes in a row and the 101st roll would still be a 1/6 chance; no more likely then the first roll.  A die is just a piece of wood or plastic, the way physics behaves on it remains the same.

If we are speaking of probability before the events occur, then it is correct to say that over the course of 6 rolls, on average 3 will be heads and 3 will be tails.

But yes, once you actually start making the flips, you cannot make any determinations of the next flip, based on the previous ones.

Same with mining. One can calculate beforehand, the average number of shares that they might submit for a given difficulty over a period of time, but the actual results will vary and have no bearing on previous results.  A higher difficulty is going to to have a higher  variance, and one can argue that a lower difficulty should be used to provide more "fair" (or even) payouts over the short term. But if you are mining for weeks/months, it should all even out. Some days you will be unlucky and get less than you "should", other days you will be lucky and get more than you "should".

The whole point of difficulty is to let the pool know how much you are working. Ideally you would submit every single *hash* that you produce to the pool. In that case the pool's hashrate would exactly match your hashrate, and you would be paid perfectly based on your percentage of work. But that's obviously completely impractical. With a higher difficulty, you submit shares less often, which will cause some variance between your hashrate, and the hashrate that the pool assumes you are producing. The tradeoff between difficulties is reasonable to debate, but it boils down to how long a period of time is required to even out the variance.

I personally believe that the current difficulty is too high for low hashers to receive a reasonable variance, but that's just my opinion.

[btcdrak]

Actually, while we are on the topic. Can someone explain how mining pools prevent people from just submitting a found block as their own? So normally a pool miner submits shares to prove they are working on a block. If they happen to find the block, surely the could just submit it as their own? Or am I missing something?

[ranlo]

I'll ask again since nobody replied the last time...

If difficulty doesn't matter, why do pools even have a choice on what difficulty to go with? Why is there VarDiff? Since difficulty is meaningless, people who spent all the time developing those systems (as well as those who implemented them into their miners) wasted their time on something that supposedly means absolutely nothing.

Since difficulty has no real value, every pool/miner should be set at a hard-coded 1024 or 2048 or (insert difficulty here). We clearly have no need for more than one option.

[cverity]

Actually, while we are on the topic. Can someone explain how mining pools prevent people from just submitting a found block as their own? So normally a pool miner submits shares to prove they are working on a block. If they happen to find the block, surely the could just submit it as their own? Or am I missing something?

This can't happen. The solution that you are trying to solve includes the pool op's payout address.

[mueslo]

Actually, while we are on the topic. Can someone explain how mining pools prevent people from just submitting a found block as their own? So normally a pool miner submits shares to prove they are working on a block. If they happen to find the block, surely the could just submit it as their own? Or am I missing something?

As I understand it, the hash the pool gives you to crack is essentially a signature for the transaction of the block payout the pool operator wants. So if you knew where he wants to pay out, you could. But then it would payout exactly there.

I'll ask again since nobody replied the last time...

If difficulty doesn't matter, why do pools even have a choice on what difficulty to go with? Why is there VarDiff? Since difficulty is meaningless, people who spent all the time developing those systems (as well as those who implemented them into their miners) wasted their time on something that supposedly means absolutely nothing.

Since difficulty has no real value, every pool/miner should be set at a hard-coded 1024 or 2048 or (insert difficulty here). We clearly have no need for more than one option.

Pooled mining is all about reducing variance. Vardiff enables you to achieve the same variance throughout the range of hashrates.

I personally believe that the current difficulty is too high for low hashers to receive a reasonable variance, but that's just my opinion.

I think for anyone whose hashrate is above 250 KH/s, the current share difficulty is fine if you mine for more than 24h.

[btcdrak]

I'll ask again since nobody replied the last time...

If difficulty doesn't matter, why do pools even have a choice on what difficulty to go with? Why is there VarDiff? Since difficulty is meaningless, people who spent all the time developing those systems (as well as those who implemented them into their miners) wasted their time on something that supposedly means absolutely nothing.

Since difficulty has no real value, every pool/miner should be set at a hard-coded 1024 or 2048 or (insert difficulty here). We clearly have no need for more than one option.

I would like to hear what OP/h20 has to say in reply to this.

[cverity]

I'll ask again since nobody replied the last time...

If difficulty doesn't matter, why do pools even have a choice on what difficulty to go with? Why is there VarDiff? Since difficulty is meaningless, people who spent all the time developing those systems (as well as those who implemented them into their miners) wasted their time on something that supposedly means absolutely nothing.

Since difficulty has no real value, every pool/miner should be set at a hard-coded 1024 or 2048 or (insert difficulty here). We clearly have no need for more than one option.

Ideally you want the lowest difficulty that doesn't overload the servers or your bandwidth, which will vary on your hashrate. If you have one GPU, you don't want the diff so high that you aren't telling the pool that you are working very often.  If you have a GPU farm, there is no need to have a low diff that is constantly sending the pool shares.

As I discussed in more detail a dozen posts or so above, it doesn't matter over the long-term, but lower difficulty will give more reasonable day-to-day variance to slow hashers.

[Damnsammit]

At first I also thought the difficulty would change things, but that's because I didn't really know how the difficulty worked

Same here!  I am very glad that I joined the discussion yesterday because I learned a lot about difficulty and mining that I thought I previously already knew.   I never thought it would change the overall profits of the pool, but like Liquidfire, I thought it was skewing the profits towards the larger hashrate miners.  That's not the case though and I found that out over the past couple of days thanks to all of the discussion and some research

[Damnsammit]

As I discussed in more detail a dozen posts or so above, it doesn't matter over the long-term, but lower difficulty will give more reasonable day-to-day variance to slow hashers.

This. 

Difficulty is most useful to curb excessive bandwidth to the pool server.

[h2odysee]

For the record, here is what I believe:

Difficulty does not affect profits. For the pool as a whole, or for miners individually, even if they have low hashrate. It only affects variance.


If I were to lower the difficulty, my database would have difficulty keeping up. In fact, some large pools charge higher fees for users that use lower difficulty settings. The bandwidth isn't really an issue. CPU usage is.

Implementing vardiff isn't as easy as switching it on, like most pools, because a lot of the code in my pool is custom, and I didn't bother with vardiff.

Even implementing a difficulty other than 512 would take a while, because I never coded for varying difficulties.

[rtgornik]

I'll ask again since nobody replied the last time...

If difficulty doesn't matter, why do pools even have a choice on what difficulty to go with? Why is there VarDiff? Since difficulty is meaningless, people who spent all the time developing those systems (as well as those who implemented them into their miners) wasted their time on something that supposedly means absolutely nothing.

Since difficulty has no real value, every pool/miner should be set at a hard-coded 1024 or 2048 or (insert difficulty here). We clearly have no need for more than one option.

https://yourlogicalfallacyis.com/appeal-to-authority

[Damnsammit]

https://yourlogicalfallacyis.com/appeal-to-authority

Bookmarked!  What a great little website

Cheers!

[cverity]

https://yourlogicalfallacyis.com/appeal-to-authority

Lol, love it!  And, of course: https://yourlogicalfallacyis.com/the-gamblers-fallacy

[Liquidfire]

https://yourlogicalfallacyis.com/appeal-to-authority

Lol, love it!  And, of course: https://yourlogicalfallacyis.com/the-gamblers-fallacy

Its not gamblers fallacy to predict the expected outcome of a series of events given a probability.

Like saying, given a set of 5 coin clips, we predict 3.125% of the time it will be all heads.


Gamblers fallacy would be:

I just had 4 heads, I am due for tails now!

or

I just had 4 heads, I am on a steak and will get heads


Calling probability gamblers fallacy is a complete reversal of the situation, the casino relies on probability to even out variance and ensure their profit over time.

When we predict the average time to find block, we are like the casino predicting the number of times the dealer wins on a game OVER TIME.


In other words, it is not gamblers fallacy to say given a hashrate of x, and a difficulty of y, we RELIABLY EXPECT it to take Z seconds to find a share.

[cverity]

Its not gamblers fallacy to predict the expected outcome of a series of events given a probability.

Like saying, given a set of 5 coin clips, we predict 3.125% of the time it will be all heads.


Gamblers fallacy would be:

I just had 4 heads, I am due for tails now!

or

I just had 4 heads, I am on a steak and will get heads


Calling probability gamblers fallacy is a complete reversal of the situation, the casino relies on probability to even out variance and ensure their profit over time.

When we predict the average time to find block, we are like the casino predicting the number of times the dealer wins on a game OVER TIME.


In other words, it is not gamblers fallacy to say given a hashrate of x, and a difficulty of y, we RELIABLY EXPECT it to take Z seconds to find a share.

Correct. I'm not speaking of probability of the expected outcome of a series of events that have not happened yet.  I'm directing that link to anyone that thinks that they calculated part of a share and lost something when we move to a new block.

[Liquidfire]

Its not gamblers fallacy to predict the expected outcome of a series of events given a probability.

Like saying, given a set of 5 coin clips, we predict 3.125% of the time it will be all heads.


Gamblers fallacy would be:

I just had 4 heads, I am due for tails now!

or

I just had 4 heads, I am on a steak and will get heads


Calling probability gamblers fallacy is a complete reversal of the situation, the casino relies on probability to even out variance and ensure their profit over time.

When we predict the average time to find block, we are like the casino predicting the number of times the dealer wins on a game OVER TIME.


In other words, it is not gamblers fallacy to say given a hashrate of x, and a difficulty of y, we RELIABLY EXPECT it to take Z seconds to find a share.

Correct. I'm not speaking of probability of the expected outcome of a series of events that have not happened yet.  I'm directing that link to anyone that thinks that they calculated part of a share and lost something when we move to a new block.

Well if anyone really thinks that, excellent use of the fallacy.

Nobody has calculated "part" of a share. What I was saying earlier, getting accused of gamblers fallacy in the process, is that when you statistically are expected to only get a share 80% of the time on a given block, due to the race condition between you finding your share and the pool finding a block, it is FUNCTIONALLY the same (over time) to say it is "AS IF" you lose 20% of your hashpower, or, put another way, 20% of each share/total shares.

Different ways of mentally imagining the scenario, each mathematically correct, while technically there is no partial share.

[joris]

0 === 32 === 59 === 95 === 119 ===   BLOCKS

0 S============SS======R===S==   SHARES SLOW MINER (lucky one)

0 ===R=RS===RRS===R=S==SR=====   SHARES FAST MINER (unlucky one: doesn't hash the data to be hashed)

Blocks and hashes are independent, share rejects happen during the communication latency around a found block.


It does'nt take x seconds to find a share, at AVERAGE your miner finds a share every x seconds.

[Liquidfire]

0 === 32 === 59 === 95 === 119 ===   BLOCKS

0 S============SS======R===S==   SHARES SLOW MINER (lucky one)

0 ===R=RS===RRS===R=S==SR=====   SHARES FAST MINER (unlucky one: doesn't hash the data to be hashed)

Blocks and hashes are independent, share rejects happen during the communication latency around a found block.


It does'nt take x seconds to find a share, at AVERAGE your miner finds a share every x seconds.

Agreed. Please understand I am not, nor was I ever talking about rejected shares.


Rejected Shares = Solving a share and submitting, but the block was already solved before you heard about it yet, so you send the share anyway.

This problem = Successfully hearing about the block change, and switching blocks... but statistically being inefficient in how you report your work complete. AKA, Leaving work unrecognized AT A HIGHER RATE than someone with a better hashrate. Higher hash rate submits shares more often, so has less "unrecognized work" still on the table when the pool changes blocks.