How pool luck is calculated, what shares are and why they are so important in pooled mining, plus the difference between estimating pool hashrate based on blocks found versus measuring pool luck.
“We haven’t found a block in X hours, is something wrong with the pool?”
Short answer: no.
Long answer: the mining rabbit hole is deep, let’s dive in.
One of the things you learn as a beginner to bitcoin mining is the purpose of network difficulty and the difficulty adjustment. In case you aren’t yet familiar with these, you can read our simple explainer, Bitcoin Mining is NOT Solving Complex Math Problems, which we will build on below.
To understand how mining pools work, fortunately you just need to apply the same concept of network difficulty, but at a smaller scale. You see, in order to find a block, miners must compute a hash which has an output below the network difficulty target. This doesn’t happen very often—on average, once every 10 minutes.
Network difficulty example: only dice rolls below “4” (network difficulty) can produce new blocks
In the article linked above, we used an analogy comparing hashing in bitcoin mining to rolling many-sided dice. The network difficulty target says how low the dice roll needs to be to produce a block.
Similarly, in order to earn a reward from a bitcoin mining pool, you have to compute a hash which has an output below what’s known as the “share difficulty target”. This is a middleground… much easier to meet than the network difficulty target, but still difficult enough that only a tiny portion of all the hashes you’re computing will qualify.
Re-using the same dice analogy, this share difficulty could be incorporated by saying that all the dice rolls below “99” result in shares being submitted to the pool, while they still have to be below “4” to produce a new block.
Share difficulty example: Dice rolls below “99” (share difficulty) can produce shares, while they still have to be below “4” to produce blocks
Summary:
Anytime your ASICs produce shares, they are sent to the pool to earn mining rewards. To verify the validity of the shares you submitted, the pool simply repeats the same hash computation that you did to produce the shares in the first place. Getting the same result verifies that the proof of work is valid. (Note: “stale” or “rejected” shares can occur when you submit shares after the block for those shares has already been found, something which typically occurs in the few milliseconds immediately following a block find. This is why it’s advisable to connect to the nearest pool stratum server to your geographic location.)
From this description, can you see why shares are so important?
To verify the shares, the pool must compute the hash… meaning that, without shares, pools would have to redo ALL the hashes that miners do just to be sure that miners are actually doing the work in the first place. In other words, public mining pools couldn’t exist without shares, as they wouldn’t have an efficient way of measuring the hashrate of each miner connected to the pool in order to fairly distribute the rewards.
This also explains why your pool hashrate fluctuates somewhat even when you have perfect uptime. Sometimes you’ll “find” shares faster than expected based on your hashrate and share difficulty target, and sometimes slower. The same way that sometimes miners find 2 blocks in a matter of seconds, and other times no blocks for 30+ minutes. Variance is a part of mining at every scale. In this sense, pools and share difficulty targets are like mini versions of the bitcoin network and its network difficulty target. The same math applies to both.
One thing to note is that there is no single share difficulty target for all the miners in a pool. Since shares only exist to be a practical unit for pools to measure miners’ hashrate, the share difficulty target can be adjusted for each individual miner based on their hashrate. For example, a miner with 100 PH/s will have a higher share difficulty (i.e. lower target for the hash output value) than a miner with 15 TH/s. The goal in setting this share target is for miners to be submitting shares about once every 2-3 seconds, providing a good balance between measuring your hashrate accurately and minimizing computational intensity for the pool to verify the work of all its miners.
Before we move on, something else to understand about shares is that they aren’t produced one at a time. Rather, one hash computation which has an output below the share difficulty target produces many shares.
The number of shares produced equals the number of proofs of work done multiplied by the share difficulty. To put it simply:
To illustrate further, suppose that we have a large miner with share difficulty 10,000 and a smaller miner with share difficulty 100. Both miners submit one hash (i.e. 1 proof of work) every 2-3 seconds on average, but that 1 hash accounts for 10,000 shares for the larger miner and 100 shares for the smaller one.
This is how the pool is able to validate the work of larger miners without linearly scaling the pool’s own work. They still just need to run a single hash computation, but it represents more shares the higher the difficulty was in producing it.
If you find yourself confused by the concept of “luck” in mining, you’re not alone. In Braiins Pool's (formerly Slush Pool) 11+ year history as of 2021, luck has been the most frequent topic of questions. In order to fully grasp how it works, you first have to know about shares, which itself is not common knowledge. But now that you’ve read about shares, let’s get to luck.
Pool luck is defined as the expected number of shares to find a block divided by the actual number of shares it took for the pool to find a block. This expected number of shares is based on the network difficulty, where higher difficulty means that the expected amount of shares required will also be higher.
For a simple example with made up numbers, suppose that a pool has 10 miners each submitting 10 shares per second on average, for a total of 100 shares per second. Also suppose that the total expected number of shares to find a block with the current network difficulty is 600,000. At a rate of 100 shares/second, it will take 6,000 seconds (100 minutes) to accumulate 600,000 shares. In other words, the pool should find a block once every 1 hour and 40 minutes in this scenario, assuming constant network difficulty and pool hashrate.
Now let’s suppose the pool found a block after only 300,000 shares instead of 600,000. The pool luck for that block would be 200%, as it’s 600k/300k*100% = 200%. Alternatively, suppose it takes 1,200,000 shares to find a block. Now the luck for that block is 600k/1200k*100% = 50%.
This means that the pool luck cannot adjust until the pool finds a block, as it’s unknown how many shares it will take until the block find actually occurs. Luck is a static value that updates occasionally, not a dynamic one updating constantly.
However, you can still get a rough idea for what the luck would be if the block find occurred at the present moment by dividing the Avg. Round Duration by the actual Round Duration, shown below.
The Avg. Round Duration is calculated with the expected number of shares to find a block (based on network difficulty) and the expected amount of time to accumulate those shares (based on the pool’s hashrate). Fluctuations in the pool hashrate impact the rate at which more shares are accumulated, increasing the Avg. Round Duration when the pool hashrate drops and vice versa when the pool hashrate goes up.
It’s also important to notice what does NOT directly impact the Avg. Round Duration, nor the pool luck: blocks mined by other miners/pools. Mining is probabilistic, and the probabilities don’t change based on past history of the pool nor the luck of other miners. Every hash is just as likely to result in a block find as every other hash. Likewise, if it’s expected that 600,000 shares will be needed for the pool to find a block, it doesn’t matter whether other miners/pools find 20 blocks or 0 blocks in that time—the only things that matter for pool luck is the quantity of shares submitted to the pool and the network difficulty. And of course, remember that luck always trends towards 100% over time—it’s just math.
Finally, let’s move on to the question most of you probably came here to answer. That is, how does all of this affect my mining rewards on Braiins Pool?
In a simple world where you are maintaining a constant share of the pool’s total hashrate, luck translates 1:1 with your actual vs. expected mining rewards. If the pool luck is 100% in a 10-block period, it means that the pool found exactly as many blocks as expected given the pool’s hashrate in that time. If your portion of the pool’s hashrate didn’t change over that 10-block period, earning 100% of expected rewards applies to you as well. Likewise, 200% luck would mean you earned 2x more than expected, while 50% luck would mean you earned 50% as much as expected.
In the real world, the answer depends. For example, if you have downtime during a period of no blocks and you have full uptime when all the 10 blocks are found, you’d earn more than expected for your hashrate when the pool has 100% luck. On the other hand, downtime during block finds would result in earning less than expected when the pool has 100% luck.
However, note that this doesn’t apply for more hashrate joining the pool. When the pool’s hashrate increases while your individual hashrate stays constant, you will earn a smaller portion of rewards for each block. At the same time, though, the increase in the pool’s total hashrate results in reaching the expected amount of shares to find a block more quickly. Put another way, it means the pool should find blocks more often, so your reward per block goes down but the frequency of block finds offsets it. (This is with constant network difficulty.)
Every hash is just as likely as any other to produce a new block, meaning there is no way to try to “time the market” so to speak. You can try to “sell high” by scheduling downtime or hopping pools right after a block find, but the probability of another block find occurring is just as likely as at any other time. You can also try to “buy low” by joining the pool during a bad luck streak, but a long round doesn’t make it any likelier for the next hashes to result in a block find, either. In fact, since mining is pure math without any human emotion element (unlike markets), it is even more pointless to try to time it. Just keep hashing and remember that luck always trends towards 100% over time.
Since per-block pool luck is only a function of the blocks mined by the pool, it doesn’t change based on the rate at which other miners are finding blocks nor as a function of time—it’s based purely on shares. A metric which does incorporate the general passing of time and other blocks being mined is the pool’s estimated hashrate.
We estimate the hashrate of every miner / mining pool on our Bitcoin Mining Insights dashboard using the network difficulty and the number of blocks found by each entity during a given period. At the time of writing, the period we use is 720 blocks, which works out to 5 days of mining activity if the average block time is 10 minutes. (Note: this is why different dashboards can have different numbers—there’s no one “correct” way to do it.)
As long as pool operators are honest in reporting their hashrate, the reported hashrate values will always be more accurate than the estimated hashrate values because estimated hashrate incorporates the natural short-term variance in bitcoin mining. Longer time periods should reduce this variance, but using too long of a time period can cause the estimated hashrate value to significantly lag the real hashrate value. 720 network blocks is a period we feel balances these two factors.
With reported hashrate being a real-time stat while estimated hashrate is over a longer time period, it’s not precise to calculate pool luck with these two values. It can certainly give you a general idea, but any significant changes in the pool’s hashrate during the analyzed time period (720 blocks on Mining Insights) will not be reflected properly.
Final thought: no matter how long you’re in mining, the difficulty adjustment never ceases to amaze.
| Konference | Web | X | Where | When | Confirmed |
|---|---|---|---|---|---|
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell | ||
| Cell | Cell | Cell | Cell |
.svg){kind=small}
Bitcoin mining software company: Braiins Pool, Braiins OS & Stratum V2.
By miners, for miners.
Increase hashrate on your Bitcoin ASICs, improve efficiency as much as 25%, and mine on any pool or get 0% pool fees on Braiins Pool.
Reduce data transmission between your farm and pool by 95%. Configure parallel usage of multiple pools. Set a backup pool for the whole farm.
It focuses on making data transfers more efficient, reducing physical infrastructure requirements for mining operations, and increasing security
Industry leaders in transparency and innovation, with more than 1.25 million BTC mined since 2010.
Published
30.12.2021
How pool luck is calculated, what shares are and why they are so important in pooled mining, plus the difference between estimating pool hashrate based on blocks found versus measuring pool luck.
Table of Contents
“We haven’t found a block in X hours, is something wrong with the pool?”
Short answer: no.
Long answer: the mining rabbit hole is deep, let’s dive in.
One of the things you learn as a beginner to bitcoin mining is the purpose of network difficulty and the difficulty adjustment. In case you aren’t yet familiar with these, you can read our simple explainer, Bitcoin Mining is NOT Solving Complex Math Problems, which we will build on below.
To understand how mining pools work, fortunately you just need to apply the same concept of network difficulty, but at a smaller scale. You see, in order to find a block, miners must compute a hash which has an output below the network difficulty target. This doesn’t happen very often—on average, once every 10 minutes.
Network difficulty example: only dice rolls below “4” (network difficulty) can produce new blocks
In the article linked above, we used an analogy comparing hashing in bitcoin mining to rolling many-sided dice. The network difficulty target says how low the dice roll needs to be to produce a block.
Similarly, in order to earn a reward from a bitcoin mining pool, you have to compute a hash which has an output below what’s known as the “share difficulty target”. This is a middleground… much easier to meet than the network difficulty target, but still difficult enough that only a tiny portion of all the hashes you’re computing will qualify.
Re-using the same dice analogy, this share difficulty could be incorporated by saying that all the dice rolls below “99” result in shares being submitted to the pool, while they still have to be below “4” to produce a new block.
Share difficulty example: Dice rolls below “99” (share difficulty) can produce shares, while they still have to be below “4” to produce blocks
Summary:
Anytime your ASICs produce shares, they are sent to the pool to earn mining rewards. To verify the validity of the shares you submitted, the pool simply repeats the same hash computation that you did to produce the shares in the first place. Getting the same result verifies that the proof of work is valid. (Note: “stale” or “rejected” shares can occur when you submit shares after the block for those shares has already been found, something which typically occurs in the few milliseconds immediately following a block find. This is why it’s advisable to connect to the nearest pool stratum server to your geographic location.)
From this description, can you see why shares are so important?
To verify the shares, the pool must compute the hash… meaning that, without shares, pools would have to redo ALL the hashes that miners do just to be sure that miners are actually doing the work in the first place. In other words, public mining pools couldn’t exist without shares, as they wouldn’t have an efficient way of measuring the hashrate of each miner connected to the pool in order to fairly distribute the rewards.
This also explains why your pool hashrate fluctuates somewhat even when you have perfect uptime. Sometimes you’ll “find” shares faster than expected based on your hashrate and share difficulty target, and sometimes slower. The same way that sometimes miners find 2 blocks in a matter of seconds, and other times no blocks for 30+ minutes. Variance is a part of mining at every scale. In this sense, pools and share difficulty targets are like mini versions of the bitcoin network and its network difficulty target. The same math applies to both.
One thing to note is that there is no single share difficulty target for all the miners in a pool. Since shares only exist to be a practical unit for pools to measure miners’ hashrate, the share difficulty target can be adjusted for each individual miner based on their hashrate. For example, a miner with 100 PH/s will have a higher share difficulty (i.e. lower target for the hash output value) than a miner with 15 TH/s. The goal in setting this share target is for miners to be submitting shares about once every 2-3 seconds, providing a good balance between measuring your hashrate accurately and minimizing computational intensity for the pool to verify the work of all its miners.
Before we move on, something else to understand about shares is that they aren’t produced one at a time. Rather, one hash computation which has an output below the share difficulty target produces many shares.
The number of shares produced equals the number of proofs of work done multiplied by the share difficulty. To put it simply:
To illustrate further, suppose that we have a large miner with share difficulty 10,000 and a smaller miner with share difficulty 100. Both miners submit one hash (i.e. 1 proof of work) every 2-3 seconds on average, but that 1 hash accounts for 10,000 shares for the larger miner and 100 shares for the smaller one.
This is how the pool is able to validate the work of larger miners without linearly scaling the pool’s own work. They still just need to run a single hash computation, but it represents more shares the higher the difficulty was in producing it.
If you find yourself confused by the concept of “luck” in mining, you’re not alone. In Braiins Pool's (formerly Slush Pool) 11+ year history as of 2021, luck has been the most frequent topic of questions. In order to fully grasp how it works, you first have to know about shares, which itself is not common knowledge. But now that you’ve read about shares, let’s get to luck.
Pool luck is defined as the expected number of shares to find a block divided by the actual number of shares it took for the pool to find a block. This expected number of shares is based on the network difficulty, where higher difficulty means that the expected amount of shares required will also be higher.
For a simple example with made up numbers, suppose that a pool has 10 miners each submitting 10 shares per second on average, for a total of 100 shares per second. Also suppose that the total expected number of shares to find a block with the current network difficulty is 600,000. At a rate of 100 shares/second, it will take 6,000 seconds (100 minutes) to accumulate 600,000 shares. In other words, the pool should find a block once every 1 hour and 40 minutes in this scenario, assuming constant network difficulty and pool hashrate.
Now let’s suppose the pool found a block after only 300,000 shares instead of 600,000. The pool luck for that block would be 200%, as it’s 600k/300k*100% = 200%. Alternatively, suppose it takes 1,200,000 shares to find a block. Now the luck for that block is 600k/1200k*100% = 50%.
This means that the pool luck cannot adjust until the pool finds a block, as it’s unknown how many shares it will take until the block find actually occurs. Luck is a static value that updates occasionally, not a dynamic one updating constantly.
However, you can still get a rough idea for what the luck would be if the block find occurred at the present moment by dividing the Avg. Round Duration by the actual Round Duration, shown below.
The Avg. Round Duration is calculated with the expected number of shares to find a block (based on network difficulty) and the expected amount of time to accumulate those shares (based on the pool’s hashrate). Fluctuations in the pool hashrate impact the rate at which more shares are accumulated, increasing the Avg. Round Duration when the pool hashrate drops and vice versa when the pool hashrate goes up.
It’s also important to notice what does NOT directly impact the Avg. Round Duration, nor the pool luck: blocks mined by other miners/pools. Mining is probabilistic, and the probabilities don’t change based on past history of the pool nor the luck of other miners. Every hash is just as likely to result in a block find as every other hash. Likewise, if it’s expected that 600,000 shares will be needed for the pool to find a block, it doesn’t matter whether other miners/pools find 20 blocks or 0 blocks in that time—the only things that matter for pool luck is the quantity of shares submitted to the pool and the network difficulty. And of course, remember that luck always trends towards 100% over time—it’s just math.
Finally, let’s move on to the question most of you probably came here to answer. That is, how does all of this affect my mining rewards on Braiins Pool?
In a simple world where you are maintaining a constant share of the pool’s total hashrate, luck translates 1:1 with your actual vs. expected mining rewards. If the pool luck is 100% in a 10-block period, it means that the pool found exactly as many blocks as expected given the pool’s hashrate in that time. If your portion of the pool’s hashrate didn’t change over that 10-block period, earning 100% of expected rewards applies to you as well. Likewise, 200% luck would mean you earned 2x more than expected, while 50% luck would mean you earned 50% as much as expected.
In the real world, the answer depends. For example, if you have downtime during a period of no blocks and you have full uptime when all the 10 blocks are found, you’d earn more than expected for your hashrate when the pool has 100% luck. On the other hand, downtime during block finds would result in earning less than expected when the pool has 100% luck.
However, note that this doesn’t apply for more hashrate joining the pool. When the pool’s hashrate increases while your individual hashrate stays constant, you will earn a smaller portion of rewards for each block. At the same time, though, the increase in the pool’s total hashrate results in reaching the expected amount of shares to find a block more quickly. Put another way, it means the pool should find blocks more often, so your reward per block goes down but the frequency of block finds offsets it. (This is with constant network difficulty.)
Every hash is just as likely as any other to produce a new block, meaning there is no way to try to “time the market” so to speak. You can try to “sell high” by scheduling downtime or hopping pools right after a block find, but the probability of another block find occurring is just as likely as at any other time. You can also try to “buy low” by joining the pool during a bad luck streak, but a long round doesn’t make it any likelier for the next hashes to result in a block find, either. In fact, since mining is pure math without any human emotion element (unlike markets), it is even more pointless to try to time it. Just keep hashing and remember that luck always trends towards 100% over time.
Since per-block pool luck is only a function of the blocks mined by the pool, it doesn’t change based on the rate at which other miners are finding blocks nor as a function of time—it’s based purely on shares. A metric which does incorporate the general passing of time and other blocks being mined is the pool’s estimated hashrate.
We estimate the hashrate of every miner / mining pool on our Bitcoin Mining Insights dashboard using the network difficulty and the number of blocks found by each entity during a given period. At the time of writing, the period we use is 720 blocks, which works out to 5 days of mining activity if the average block time is 10 minutes. (Note: this is why different dashboards can have different numbers—there’s no one “correct” way to do it.)
As long as pool operators are honest in reporting their hashrate, the reported hashrate values will always be more accurate than the estimated hashrate values because estimated hashrate incorporates the natural short-term variance in bitcoin mining. Longer time periods should reduce this variance, but using too long of a time period can cause the estimated hashrate value to significantly lag the real hashrate value. 720 network blocks is a period we feel balances these two factors.
With reported hashrate being a real-time stat while estimated hashrate is over a longer time period, it’s not precise to calculate pool luck with these two values. It can certainly give you a general idea, but any significant changes in the pool’s hashrate during the analyzed time period (720 blocks on Mining Insights) will not be reflected properly.
Final thought: no matter how long you’re in mining, the difficulty adjustment never ceases to amaze.
Read Privacy Policy.
.jpg)
24.9.2024
20.9.2024
24.8.2024
Read Privacy Policy.
.svg)