Why No Pool Can Make You Luckier

We hear it all the time. "My best shares are bigger on Pool X." "I find better shares more often on Pool Y." "I reboot my miner every few days to shake up my luck."

It's easy to see why people believe this. Mining is a game of chance, and humans are wired to find patterns in chance. But a pool, including AtlasPool, can't make your miner's hashes any luckier. The work a pool sends does decide which hashes your miner calculates, but it can't tilt them toward better results. To see why, it helps to look at what a hash is and who controls what goes into it.

What your miner actually does

Bitcoin mining uses an algorithm called SHA-256d, which is SHA-256 run twice: the miner hashes the data, then hashes the result. The input is an 80-byte block header. The output is a 256-bit number that looks completely random.

SHA-256d has two properties that matter here. The first is the Avalanche Effect: change even a single bit of the input, and about half of the output bits flip. Inputs that look almost identical produce outputs that look completely unrelated. The second is that nobody knows a shortcut for predicting a hash. To find out what a header hashes to, a miner has to do the calculation.

A share's "difficulty" is just a measure of how small its hash is. A smaller hash means a higher difficulty. Your best share is the smallest hash your miner has found so far. In solo mining, the only share that pays is one whose difficulty meets or exceeds the current network difficulty. That share becomes a block, as long as the pool can submit the full, valid block to the network in time.

Template, job, header: what's the difference?

These three terms get mixed up a lot.

• Block template. The pool asks its Bitcoin node for a candidate block: the transactions to include, the block reward, and the other fields a block needs. This is the full blueprint, often several thousand transactions.
• Stratum job. The pool can't send megabytes of transactions to every miner every few seconds. Instead it sends a compact job: the coinbase transaction split into two halves, plus a short list of "merkle branch" hashes that stand in for all the other transactions.
• Block header. The miner turns the job into an 80-byte header. The header is what actually gets hashed, trillions of times per second. It commits to every transaction through a single 32-byte fingerprint called the merkle root.

So a header is not the same thing as a template. The header is the small summary of the template that the miner hashes.

A real AtlasPool header, byte by byte

To make this concrete, we connected to solo.atlaspool.io:3333, received a job for block 974,291, and built the header the same way a miner would.

Here's where each piece came from.

From the pool:

• Version (0x20000000).
• Previous block hash (00000000000000000001bcd5…), which tells the miner to build on block 974,290. Inside the header, Bitcoin stores hashes in the reverse of the order people normally write them, which is why the zeros show up at the end in the figure.
• The coinbase transaction, sent in two halves. In this job it contains the block height (974,291), the pool tag AtlasPool/IAD, and three outputs:
  • 3.10260594 BTC to the address the miner connected with. On a solo pool, that's your address.
  • 0.0472478 BTC to AtlasPool, its 1.5% fee.
  • A zero-value "witness commitment" output that every block with SegWit transactions needs.
• Twelve merkle branches, representing the rest of the block's transactions.
• Time (0x6ae8e8ce), a standard Unix timestamp: 1,793,648,846 seconds since January 1, 1970, which is 19:47:26 UTC on November 2, 2026.
• Bits (0x1701e5ac), the network's difficulty target in compact form, about 148.4 trillion.

From the miner:

• Extranonce2. The miner inserts its own value between the two coinbase halves, then combines the coinbase with the merkle branches to compute the merkle root. Each new extranonce2 gives a completely new merkle root.
• Nonce. A 32-bit counter the ASIC cycles through, about 4.3 billion values per merkle root.
• Version and time rolling (optional). The pool supplies the starting version and time. Within limits the pool allows, the miner can adjust a few version bits or nudge the time forward to get even more combinations to try.

You won't find your payout address in the 80 header bytes themselves. It lives in the coinbase transaction, and the coinbase is folded into the merkle root. Change the address and the merkle root changes, and so does every hash. The pool also gives every connection its own extranonce1, so even two miners paying the same address work through different headers and don't repeat each other's work.

The Avalanche Effect in action

Here is that same header hashed three times. The only change is the nonce: 0, then 1, then 2.

A quick note on how to read these numbers: a hash is 256 ones and zeros. Writing all of them out would take 256 characters, so hashes are almost always written in hexadecimal (hex). Each hex character (0–9, a–f) stands for exactly 4 bits, so 64 hex characters hold the full 256-bit hash. Hex is just a shorter way of writing the same number.

Only one or two bits of the input change, yet each output looks completely different. Nearly every hex character is different, and underneath, any two of these hashes differ in about half of their 256 bits. Half is exactly what you'd expect from unrelated random numbers. Nothing about the first hash hints at the second. That's what your miner does trillions of times a second: draw a fresh, unpredictable number on every try.

Why the pool can't steer the outcome

Think about what "making a miner luckier" would actually require. The pool would need to know ahead of time which job contents hash lower than others. The only known way to find out is to compute the hashes, which is mining. A pool that could predict good hashes wouldn't need your miner at all. It would also have broken SHA-256, which would be far bigger news than a mining pool.

Different jobs do produce different hashes. But every valid header has exactly the same odds as any other, no matter which pool it came from. Whether a job comes from AtlasPool or anyone else, each hash your miner computes has the same chance of being a big share.

So why do some pools seem luckier?

The size and timing of best shares vary wildly. A miner can go weeks with modest shares and then land one that's 100 times bigger than usual. With thousands of miners comparing screenshots, someone always has an amazing story, and every pool's community has a few of them.

There's only one rule of thumb you need: your typical best share grows in proportion to the total number of hashes you've done, which is hashrate multiplied by time. Double your hashrate or your mining time, and your typical best share roughly doubles. Your choice of pool doesn't enter into it.

Confirmation bias

Psychologists have a name for the biggest reason pools seem different: confirmation bias. Once we believe something, we tend to notice and remember the evidence that supports it, and overlook the evidence that doesn't.

Here's how it plays out in mining. A miner hears that Pool X is "lucky" and points a Bitaxe at it. A week later, a big best share shows up, and it feels like proof. The weeks of ordinary shares on Pool X don't register, and neither do the big shares the same miner found on other pools. Then the screenshot gets posted, and other people's beliefs get a little stronger. Nobody is being dishonest. That's simply how human memory works when it's sorting through random events.

The fix is to count everything, not just the moments that stand out. When miners compare full records over the same hashrate and a long enough time, the "lucky pool" effect fades away. Some random difference always remains, but it doesn't favor any particular pool.

A couple of other habits of mind make the illusion stronger:

• We switch after bad streaks. If you change pools after a rough stretch, the next stretch will probably look better, simply because the rough stretch was unusual. The new pool gets the credit.
• Comparisons often aren't fair. Different hashrates, different time windows, and dashboards that reset at different times all make side-by-side comparisons misleading.

What about rebooting?

Miners like the Bitaxe and NerdQAxe track two numbers: a session best (since the last reboot) and an all-time best. Rebooting resets only the session best.

On a long uninterrupted run, each new session record is harder to beat than the last, so new records come along less and less often. After a reboot, the session counter starts from zero, and new session bests start appearing again quickly. That can feel like a lucky streak, but the odds of every hash are exactly the same as before.

Watch your all-time best instead. A reboot can't help it, because the hashes after a reboot are no better than the hashes before. Rebooting actually costs you a little, because your miner isn't hashing while it restarts.

What does matter

A pool can't change the odds of any single hash. It can affect how many of your hashes count. Three things matter most.

1. Uptime

A miner that isn't connected isn't mining. Pool outages, dropped connections and failover delays all mean lost hashes, and every lost hash is a lost lottery ticket. A pool you can count on to stay up is worth more than any "lucky" reputation.

At AtlasPool, if an endpoint ever has a problem, it's automatically withdrawn, and miners reconnect to the closest healthy location.

2. Block notification speed

When someone finds a new block anywhere on the network, every miner needs to start building on the new tip immediately. Until your pool sends a new job, your miner keeps hashing on the old tip. A block found during that window would start the race to be accepted already behind. It would very likely lose, becoming what's called a stale block, which earns nothing.

Blocks arrive about every 600 seconds on average. So each second of notification delay wastes roughly 1/600, or about 0.17%, of your hashing on average. Some blocks come quickly and some take much longer, so the exact loss varies from block to block. The amount is small. But it's real, it adds up over thousands of blocks, and it's one of the few things a pool actually controls.

Some pools speed up notification by first sending a job with no transactions (only the coinbase), and then following up with a full job a little later. That gets miners onto the new tip quickly, but a block found on the empty job gives up all the transaction fees. AtlasPool focuses on sending miners a new job built from the full block template, transactions included, as quickly as possible. At the time of writing, stratumrace.com ranks AtlasPool first for full-template block notification. The rankings are measured live, so follow the link to see the current results.

3. Latency

Latency is the time it takes data to travel between your miner and the pool, usually measured in milliseconds. It matters in both directions. New jobs reach your miner a little later, so latency adds to the notification delay described above. The shares your miner finds also reach the pool a little later. If a share was found on work for a block that's no longer the tip, the pool rejects it as stale.

Shares can be rejected for other reasons too, such as duplicates or misconfigured miners, so check the rejection reason on your dashboard before blaming latency. On a solo pool, everyday shares are mainly a health check for your miner and connection. The share that truly counts is the rare one that meets the network difficulty, and you want that one to arrive as fast as possible.

To keep this in perspective, an extra 100 milliseconds of delay in receiving new work costs about 0.02% of your hashing (0.1 second out of an average 600). A stable connection matters more than shaving off a few milliseconds. Still, the shorter the distance between you and the pool, the better.

AtlasPool handles this for you. Its stratum address, solo.atlaspool.io, is announced with BGP Anycast from more than 130 points of presence worldwide. Internet routing sends your miner to a nearby point of presence, usually the closest one, and from there AtlasPool carries the connection to the closest of its nine stratum endpoints: Ashburn, Portland, São Paulo, Frankfurt, London, Hong Kong, Mumbai, Sydney and Cape Town. You use the same hostname no matter where you are.

Each endpoint stamps the three-letter IATA code of its nearest airport into the coinbase. That's why the job behind Figure 1 carries the tag AtlasPool/IAD: our test connection was routed to the Ashburn, Virginia endpoint, near Washington Dulles International Airport (IAD).

The bottom line

No pool can make your hashes luckier. SHA-256d makes sure of that. Every hash is an independent draw. What a pool can do is keep you connected, get you onto the newest block as quickly as possible, and stay out of your way.

That's what we focus on at AtlasPool. The rest is up to your hashrate and a little bit of luck.