Topic: [ANN] profit switching auto-exchanging pool - www.middlecoin.com - page 472. (Read 829908 times)

What people aren't realizing is that the system is set up to give a rate of x%. That's mathematical.

If your rate is below that, for it to become accurate it then has to boost above it.

Ex. there are two blocks. The blockchain has a time of 30s.

Block 1: 15s
Block 2: 30s

For the average (average means add all three and divide by the total number) to equal 30 ((15+30+x)/3=30) you would need the last one to be:

Block 3: 45s

This is an ongoing process. If every block was above 30s, it would be impossible for the average to be 30s. That's just not how math works. The average is the average; if you change it, the average is no longer the average. For some reason, a lot of people here somehow can't grasp that concept.

So why does this matter?

You have a hash rate that statistically will take 1m to submit a share. A block is found in 30s.

Statistically, you will submit a share on a very small number of the blocks. For every block you DO submit one on, statistically speaking there are a MINIMUM of two more that you didn't. Why?

Block 1: 60s
Block 2: x
Block 3: x

(60 + x + x) / 3 = 20, x = 20

If the block took longer than 60s to be found, the number of blocks you would miss would go up even more. Let's say one was two minutes:

(120 + x + x + x + x + x) / 6 = 20, x = 20

Now you got a submit on one block but you missed 5 more in the process.

In other words, STATISTICALLY (mathematically proven, by the sheer nature of what an average is) you will always lose more than you gain. There's no other possible way to view it. If it were any other way, the average would no longer be the average and the entire concept of Bitcoin (and its derivatives) would be thrown out the window as being a failed concept.

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.

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.

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.

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.

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.

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

Bookmarked!  What a great little website

Cheers!

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

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.

This. 

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

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

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.

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

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.


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


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

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

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.

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?

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.

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.