Mining pool success rate

[morggin]

How often do the mining pools win the POW challenge nowadays?  Who are the major competitors to contend against?  Can there be a back-to-back winner or do winners for the POW challenge get excluded from the next challenge round?

[1714976751]

1714976751

[1714976751]

1714976751

[1714976751]

1714976751

[hosseinimr93]

How often do the mining pools win the POW challenge nowadays?  Who are the major competitors to contend against?

The chance of being the first mining pool to solve the proof of work problem depends on computation power of the mining pool.
For example, if a mining pool own 20% of the total computation power, they have 20% chance to solve the proof of work problem faster than others and win the block reward.

You can see pools ranking on mempool.space.

Can there be a back-to-back winner or do winners for the POW challenge get excluded from the next challenge round?

There's nothing that stop a mining pool from mining consecutive blocks.

[mikeywith]

For example, if a mining pool own 20% of the total computation power, they have 20% chance to solve the proof of work problem faster than others and win the block reward.

The word "faster" is probably misleading and wrong to use, it doesn't matter how fast you are, blocks are found once every 10 minutes on average regardless. also, keep in mind that miners are not working on the same block, and there is no such thing as "the next block", every miner is working on a different unique block candidate, a pool that has 20% of the hashrate is very likely to find 20% of the blocks at no exact order, speed or pace.

Can there be a back-to-back winner or do winners for the POW challenge get excluded from the next challenge round?

There is no "next challenge round", as explained above, miners create their own blocks, and to keep this "chain" theory intact, they all have the previous block hash in common when a miner manages to construct a valid block, they inform the rest of the network and everybody continue to do exactly they were doing with the expectation of using the "new block hash" and deleting the transactions that have been already included.

[hosseinimr93]

The word "faster" is probably misleading and wrong to use, it doesn't matter how fast you are, blocks are found once every 10 minutes on average regardless. also, keep in mind that miners are not working on the same block, and there is no such thing as "the next block", every miner is working on a different unique block candidate, a pool that has 20% of the hashrate is very likely to find 20% of the blocks at no exact order, speed or pace.

Let's say the last block that has been mined is block number n. Now all miners (or mining pools) are trying to mine block number n+1 and there's a competition between them for that.
The miner (or a mining pool) that finds a block header which result to a number below the target if it's hashed twice through SHA-256 function wins the competition. This is why I used the word "faster". All miners (or mining pools) try to find a good block header faster than other miners and be the one who broadcast a good block header to the network.

The chance of a mining pool with 40% of the total computation power to win the competition is twice the chance of a mining pool with 20% of the total computation power.
In the long term, it's expected that the the mining pool with 40% of the total computation power mine twice as many blocks as the mining pool with 20% of the total computation power.


Correct me if I am wrong, please.
I know blocks are always mined at the rate of 1 per ~ 10 minutes on average and each mining pool can have their own candidate block.

[mikeywith]

Let's say the last block that has been mined is block number n. Now all miners (or mining pools) are trying to mine block number n+1 and there's a competition between them for that.

Nop, when the last block has been mined, every miner is trying to mine A block, it just so happens that it gets the number n+1,

used the word "faster". All miners (or mining pools) try to find a good block header faster than other miners and be the one who broadcast a good block header to the network.

This isn't how it works, using the word faster is simply wrong here, it makes it sound like mining is just like a car race where when one car reaches the finish line, everyone goes back to the start line and races for another round, this obviously isn't the case, because if it was, then all blocks would have been won by the fastest miner, which is what you would expect in a car race whereby the faster car would always win the race, mining is not like that and that's why a miner with a tiny fraction of hashrate can find block n+1 "before" the large pools who have the remaining 99.9999999999999999% of the hashrate.

The chance of a mining pool with 40% of the total computation power to win the competition is twice the chance of a mining pool with 20% of the total computation power.
In the long term, it's expected that the the mining pool with 40% of the total computation power mine twice as many blocks as the mining pool with 20% of the total computation power.

That's correct, having twice the hashrate means you are able to try twice as much to solve puzzles, it doesn't mean you can do it faster in a sense of a "race", I believe the key point you need to understand here is that when pool x solves a block, it has exactly ZERO affect on pool y's chances of hitting their own block, what other miners solve is irrelevant to you as a miner, the outcome of you hashing your own block is completely independent of every other miner.

I think what makes all the confusion is the block height because blocks go in order "chain", it gives the illusion that if someone found block n+1 it means they won against everyone else and then everything magically resets and they head for another round of block n+2 which as I explained isn't the case, simply everyone is randomly and independently solving blocks, it just so happen that blocks found are labeled/named/numbered in a series of n+1,,,, etc.

The only race miners take is AFTER they solve a block, not before, when you solve a block and tell the network to register it as block n+1, you want to make sure you do that before someone else does -- because at any given moment, you may solve a block and in the same exact second 2 other miners solve a block, here begins the race that would decide which of the 3 blocks is going to be registered in the blockchain as block number n+1, everything before that is far from a race.

Keep in mind that all 3 blocks are VALID based on the protocol, if there was a kind of a race in solving the actual block then only one block would have been valid, but all three blocks are because essentially they are just valid blocks, the miner with the best connectivity to other nodes would likely be the one who manages to make the network recognize his block as block n+1.
 

[hosseinimr93]

Thank you mikeywith for your detailed explanation.

Nop, when the last block has been mined, every miner is trying to mine A block, it just so happens that it gets the number n+1,

I don't understand this.
So, it's possible that a miner is trying to mine block number n+2, while block number n is the last block and the block number n+1 has not been mined.
Am I getting you correctly? If so, how is that possible? How can you mine block number n+2 without knowing the hash of block number n+1?

Isn't that all miners are trying to mine the block number n+1 and they start to mine block number n+2 once they receive block number n+1 and confirm that it's valid?

This isn't how it works, using the word faster is simply wrong here, it makes it sound like mining is just like a car race where when one car reaches the finish line, everyone goes back to the start line and races for another round, this obviously isn't the case, because if it was, then all blocks would have been won by the fastest miner, which is what you would expect in a car race whereby the faster car would always win the race, mining is not like that and that's why a miner with a tiny fraction of hashrate can find block n+1 "before" the large pools who have the remaining 99.9999999999999999% of the hashrate.

Sorry, I still don't understand why the word "faster" isn't correct here.
To me, mining is like a race, but it's not that there's a fastest car that always wins the race. Sometimes car A wins the race, sometimes car B wins the race and so on.

Let's say there are only two miners. You and me. You have 70% of the total hash power and I have 30% of the total hash power.
Now we both are trying to mine a block. I am trying to be faster than you and be the one who mine the block. I have 30% chance to mine the block (or 30% chance to reach the finish line before you).
Sometimes I am faster than you and sometimes you are faster than me.

I think what makes all the confusion is the block height because blocks go in order "chain", it gives the illusion that if someone found block n+1 it means they won against everyone else and then everything magically resets and they head for another round of block n+2 which as I explained isn't the case, simply everyone is randomly and independently solving blocks, it just so happen that blocks found are labeled/named/numbered in a series of n+1,,,, etc.

You are right. I also think that that's where my confusion comes from.
I still can't understand how is it possible that a miner can try to mine block number n+2 while block number n+1 hasn't been mined yet.

[NotFuzzyWarm]

I don't understand this.
So, it's possible that a miner is trying to mine block number n+2, while block number n is the last block and the block number n+1 has not been mined.
Am I getting you correctly? If so, how is that possible? How can you mine block number n+2 without knowing the hash of block number n+1?

Isn't that all miners are trying to mine the block number n+1 and they start to mine block number n+2 once they receive block number n+1 and confirm that it's valid?

That is where the miner/pool connection times and latency come into play: ie how fast is the block found message transmitted and picked up by the other miners/pools. That can lead to orphan races where 2 or more nodes report a found block but their block has not yet been confirmed or declared block n. Which one of the blocks was was found 1st is not the important thing - which block is confirmed first is.

Until another miner picks it up, then builds their new work on it and then finds another block so the 'race' block is confirmed it's anyone's guess who will win out. That is the reason most companies will not consider a block to be valid until it is confirmed at least 3x. The Blockchain protocol itself does not consider a block to be fully valid until 101 confirmations but most companies are happy to take the risk with only 3 confirmations.

[mikeywith]

I don't understand this.
So, it's possible that a miner is trying to mine block number n+2, while block number n is the last block and the block number n+1 has not been mined.

The block number/height is not a part of the block, it is not used anywhere inside the block, when miners are hashing blocks they don't specify something like "we are now mining block n+1, they are mining a random block.

What changes in the process is that in order to mine the next block you need the hash of the previous block, not the number of the previous block.

To explain further, you can assume all miners mine empty blocks just to keep the transaction out of it, so miner A now has this data that he is hashing in order to solve a block

Previous block hash + data + nonce
Let's say it is

4444 + 123 +1 so hashing goes on with a different nonce

4444+123+1
4444+123+2
4444+123+3

Lets say at this point miner B hit their own block, they would inform miner A, miner is here isn't going to start form scratch, it is not like he lost the race, he would just start hasing using the new block hash

5555+123+1

At any given second here miner A can hit a block, or 5 in a row, miner A's ability to hit block is directly related to how many hashes he can perform, it has nothing to do with how many blocks miner B can find or how "fast" miner B does find blocks.

I am probably not good in explaining things, but I think it gets clearer when you really understand that blocks are found by brute force randomness, most online articles say it's solving complex equations, that gives the illusion that all miners are trying to solve the same puzzle, but they are not.

Miners do not solve block n+1, they solve a random block, when they do, the other nodes will label it as block n+1, it was never block n+1 before it was sent to the other nodes, it was just a valid block that meets all consensus.

[kano]

heh - actually while I'm not in any way contradicting your explanation,
since it is correct, however one minor correction, is that the block number is in the block's coinbase transaction.

The first bytes of the coinbase sig must contain the block number.
Thus the block's merkleroot effectively contains the block number.

The reason this was added later, but not there originally, was due to the risk of duplicate coinbase transaction numbers.
I'm pretty sure there was once a case of a duplicate transaction number, and this was the fix to ensure it didn't happen again.
The coinbase transactions originally didn't actually know the block they were in,
so a pool could generate 2 coinbase transactions, at different times, for different blocks, with the same transaction hash.
Adding the block height to the coinbase transaction sig, meant that the coinbase transaction contents couldn't be the same.

--

Anyway, it's not a 'success rate', it's simply an 'expected' number of blocks for a given amount of work.

While all the other small pools get this calculation wrong (and falsely show better luck numbers than they are getting)
the 'expected' number of blocks is simply 1 per 100% of work done.
The 100% number is calculated as the sum of all (work/netdiff) per every 2016 blocks

The catch there being that you can't divide your total final work by the current network difficulty, since that's faking better results for small pools.
An example would be, if you have done 50% work in the previous 2016 blocks, that 50% says fixed, and you add on top of that the amount of work you have done in the current 2016 blocks ... and so on over time until you find your next block.
On all the (other) small pools, that 50% suddenly drops after a diff increase, since they are not storing that 50%, but recalculating it incorrectly at the new network difficulty at the time the block is found.

I posted this simpler explanation in ckpool solo, but he didn't want his miners to know and deleted it:

Sigh - now even you are stating clearly incorrect comments about your stats.

You can't just divide work/"current network diff"
That is far from correct.
Even if it's only 3 weeks, it's still incorrect.
It fakes your stats to look better than they really are.

If you do 50% expected work on a block, then diff changes up, you've still done 50% expected work on a block.
You haven't magically done less expected work.

Your pool doesn't record the necessary information to give correct stats.
When a block takes only a few month, the stats you are quoting are noticeably incorrect.

e.g. on my pool since our last block in Jan, we've done 37.87T work
Today's diff is 83.1T
Divide them to get the wrong answer and you get 45.6%
My web site of course shows the correct value, which is 48.9%
So over only 3 months, that figure is wrong by more than 3%
When diff is going up faster, it of course will be wrong by a larger amount.

The simplest way to explain this without math is as follows:
A picked 5 apples off their local tree
B picked 6 apples off their local tree
No other information is provided.
Who did the best?

You have no idea, since you've no idea what type of apples they where.
Were they even ripe? How much did they weigh? Were they edible? etc.
i.e. until you know some relative value of each apple, you can't compare them.

All shares have a relative value, based not only on their diff, but also on the diff at the time they were successfully submitted.