A Bitcoin mining share is a proof-of-work hash that beats the easy target your pool assigns but not the full network target. It earns nothing on its own. It proves your miner is hashing, lets the pool measure your hashrate, and guarantees that if one of those hashes ever clears network difficulty, 127.45 trillion as of September 6, 2026, it is broadcast as a block immediately. A 1 TH/s miner submits about 14 shares a minute at a share difficulty of 1,000. One such share, from a roughly 1 TH/s board, solved block 957,382 in July 2026. This guide explains the mechanism end to end, with diagrams at each step, and applies to any stratum miner from a single-chip desktop board to an industrial ASIC.
Key takeaways
- Shares and blocks are the same work judged against two targets. A block is a share whose hash also beat network difficulty (127.45 T on Sept 6, 2026).
- A share at difficulty 1,000 is about 127 billion times easier than a block. Pools set that low bar to confirm you are hashing and to estimate your hashrate.
- Expected shares per minute ≈ 14 × your hashrate in TH/s at difficulty 1,000. Pools raise share difficulty as you get faster, so share counts are not comparable between miners.
- Healthy: 99%+ accepted, under 2% rejected or stale. Above that it is almost always Wi-Fi, latency, or power, not the ASIC.
- Best difficulty grows with runtime because you have taken more draws, not because the next draw got better. It predicts nothing.
- Seven documented blocks have been found on open-source home miners since July 2024, from a single 995 GH/s board to a 130 TH/s cluster. Every one began as an ordinary share.
What is a Bitcoin mining share?
A mining share is a block-header hash that falls below the share target your pool assigned, submitted to the pool as proof that your miner performed the work.
Every SHA-256 miner does one job. It takes the current block header, changes a field called the nonce, and hashes the result twice with SHA-256. The output is a 256-bit number. If that number is below the network target, the miner has found a block worth 3.125 BTC plus fees. If it is only below the pool’s much easier share target, it is a share.
Shares and blocks are not two kinds of work. They are the same work measured against two bars. The miner does not know which one it just cleared; the pool checks every submission against both.
A useful mental model: a block requires guessing a 20-digit number exactly. A share is proof you matched the first three digits. The pool cannot see your hardware, so those partial matches are how it knows you are playing, and how fast.
Key terms
These are the words you will see on your miner’s dashboard and your pool’s stats page. Each is defined in one line here and used consistently below; the wider mining vocabulary runs to well over a hundred terms, but these are the ones this article depends on.
- Share. A hash that beats the pool’s share target. Proof of work, not a payout.
- Share difficulty. The easy target the pool assigns each worker. Adjusts automatically (vardiff) so every worker submits at a steady cadence.
- Network difficulty. The target a hash must beat to be a valid block. 127.45 T as of Sept 6, 2026; retargets every 2,016 blocks.
- Target. The maximum hash value that counts. Difficulty and target are inverses.
- Hashrate. Hashes per second. 1 TH/s is one trillion attempts per second.
- Nonce. The 32-bit header field the miner increments between attempts.
- Extranonce. Extra bytes in the coinbase transaction that give each worker its own search space, and a fresh one when the nonce wraps.
- Job. One block template plus a job ID. A new job arrives with every new block and periodically in between as transactions change.
- Accepted share. Valid, on time, credited by the pool.
- Rejected share. Failed validation: wrong job, corrupted data, or duplicate.
- Stale share. Valid work that arrived after a new block made the job obsolete. Usually counted as rejected.
- Best difficulty. The hardest share your miner has ever found. Your closest near-miss; not a predictor.
- Block reward. 3.125 BTC subsidy plus transaction fees. Halves to 1.5625 BTC at block 1,050,000, expected in 2028.
- Coinbase transaction. The first transaction in a block. It creates the reward and pays it to an address chosen by whoever built the template.
- Solo mining. Full block reward to the finder; nothing until then. Also called lottery mining.
- Pool mining. Rewards split among members in proportion to shares submitted.
- Solo pool. A stratum server that hands out work and broadcasts blocks but pays the whole reward to whichever miner finds one. Can be hosted or run on your own node.
- Stratum. The protocol miners and pools use to exchange jobs and shares.
Proof of work in two minutes: headers, hashes, targets
Proof of work is a search for a number: a miner repeatedly hashes an 80-byte block header until the output is smaller than a target, and the smaller the target, the more hashes it takes on average.
The block header is small and fixed in size. It contains six fields:
| Field (size) | What it holds | Miner can change it? |
|---|---|---|
| Version (4 B) | Block version, signaling bits | Some bits |
| Previous hash (32 B) | Hash of the last block | No |
| Merkle root (32 B) | Fingerprint of all transactions | Via extranonce |
| Timestamp (4 B) | Unix time | Within minutes |
| Bits (4 B) | Network target, compact | No |
| Nonce (4 B) | The counter | Freely |
Bitcoin block header layout, unchanged since 2009.
SHA-256 is unpredictable: change one bit of input and the output looks completely different. There is no shortcut. The only way to find a small hash is to try inputs until one appears. The nonce gives 4.29 billion tries per header; when those run out, the miner changes the extranonce inside the coinbase transaction, which changes the Merkle root, and gets a fresh 4.29 billion.
The output of double-SHA-256 is effectively a uniformly random 256-bit number. That single fact drives every number in this article. If the target is one-thousandth of the largest possible value, one hash in a thousand lands below it. If the target is one part in 5.5 × 10²³, that is how many hashes a block costs on average.
Difficulty and target: the math behind both bars
Difficulty is a human-readable way of saying how small the target is: difficulty D means the target is D times smaller than the difficulty-1 target, and a hash below it takes D × 2³² attempts on average.
Bitcoin defines difficulty 1 as a specific, fairly large target (in hex it begins 0x00000000FFFF, so a difficulty-1 hash needs 32 leading zero bits). Because of how that constant is defined, the expected number of hashes to beat difficulty D is D × 2³², or D × 4,294,967,296. That constant appears everywhere below.
Both the share target and the network target live on this scale. The network target is set by the protocol every 2,016 blocks. The share target is set by the pool per worker. They differ only in size.
Worked example at today’s numbers:
| Bar | Difficulty | Hashes needed | Time at 1 TH/s |
|---|---|---|---|
| Share target (~1 TH/s miner) | 1,000 | 4.29 × 10¹² | 4.3 seconds |
| Share target (faster miner) | 8,192 | 3.52 × 10¹³ | 35 seconds |
| Network target | 127.45 T | 5.47 × 10²³ | ~17,300 years |
Expected hashes = difficulty × 2³². Network difficulty from block 965,664, September 6, 2026.
The ratio between the two bars, about 127 billion to one, is the whole reason shares exist. A miner that only reported blocks would be silent for millennia. A miner that reports shares speaks every few seconds.
How a hash becomes a share, step by step
The pool sends a job, the miner hashes it billions of times per second, and any result below the share target goes back to the pool, where it is checked against the share target and the network target at the same time.
- The pool builds a block template. It takes transactions from its node’s mempool, adds a coinbase transaction paying the block reward to your address (solo) or the pool’s address (pooled), and computes the Merkle root.
- The pool sends your miner a job over stratum. The job includes the previous block hash, the coinbase pieces, the Merkle branches, the version, the bits, and a timestamp. Separately, the pool tells your miner its share difficulty.
- The miner assembles the 80-byte header and starts iterating the nonce. On a modern ASIC this happens in hardware at hundreds of billions to trillions of attempts per second per chip.
- Each attempt is hashed twice with SHA-256. The result is compared to the share target. At difficulty 1,000, roughly one attempt in 4.3 trillion passes.
- A passing hash is submitted as a share. The miner sends the job ID, its extranonce, the timestamp it used, and the winning nonce. The pool rebuilds the header from those, re-hashes it, confirms the result is below the share target, and confirms the job is still current.
- Accepted. The share is logged, your hashrate estimate is updated, and the miner is already millions of hashes into the next attempt.
- The pool also compares the same hash to the network target. Almost always it is far too large. Once in roughly 127 billion shares at difficulty 1,000, it is not. The pool assembles the full block from the template and the winning header and broadcasts it to the Bitcoin network. The reward is paid to whatever address is in the coinbase.
Step 7 is why a solo miner’s payout address goes in the stratum username field. The pool bakes that address into the coinbase before you ever hash. If your share wins, the reward was already yours.
Why shares exist: a short history
Shares were invented in late 2010 when the first mining pool needed a way to split one block reward fairly among many miners, and they have been the unit of mining accounting ever since.
In Bitcoin’s first year, everyone mined solo on CPUs and blocks were findable in days or weeks. As GPUs arrived and difficulty climbed, individual miners faced months between blocks. In late 2010 the first mining pool went live with a simple idea: everyone works on the pool’s block template, submits easier-target hashes as evidence of their effort, and when the pool finds a block, the reward is divided in proportion to those easier hashes. Those easier hashes were named shares.
The idea solved two problems at once. It made payouts predictable, and it made hashrate measurable without trusting anyone. A miner cannot fake a share, because a share is a real hash that anyone can verify in microseconds. That second property is why solo pools still use shares even though there is no reward to split: the accounting is free and the verification is built in.
Inside a stratum session
Stratum is the protocol miners and pools use to exchange jobs and shares; a session is a handful of JSON messages that repeat every few seconds for as long as the miner is on.
| Message | Direction | Purpose |
|---|---|---|
| mining.subscribe | Miner → Pool | Opens the session; pool assigns extranonce1 |
| mining.authorize | Miner → Pool | Identifies the worker (solo: your payout address) |
| mining.set_difficulty | Pool → Miner | Sets share difficulty; resent on vardiff changes |
| mining.notify | Pool → Miner | Delivers a job; clean_jobs = drop old work |
| mining.submit | Miner → Pool | Sends a share: job ID, extranonce2, time, nonce |
| result | Pool → Miner | true = accepted; false + reason = rejected |
Stratum v1 as implemented by most solo pools and open-source firmware, September 2026.
Two details matter later. First, the extranonce is what lets thousands of miners work on the same template without overlapping; it is also why a share carries an “extranonce2” field. Second, clean_jobs is the mechanism behind stale shares: when it fires, anything already in flight for the old job is dead on arrival.
Why do solo miners submit shares that pay nothing?
Solo miners submit shares because the pool interface needs them to verify the miner is working, estimate its hashrate, and catch a winning hash the instant it appears.
Even solo miners do not talk to the Bitcoin network directly. The miner connects to a solo mining pool, a stratum server that builds the block template, hands out work, and broadcasts a solved block. Shares are the heartbeat of that relationship, and they do three jobs.
Proof of life. If shares stop arriving, something is wrong: Wi-Fi dropped, the power supply sagged, the ASIC overheated and throttled. Your dashboard’s accepted and rejected counters let you notice within minutes rather than days.
Hashrate estimation. The pool cannot measure your chip. It infers your hashrate from how often you submit shares at a known difficulty: hashrate ≈ shares × difficulty × 2³² ÷ seconds. That is why pool-side hashrate always wobbles more than the number on the device. It is a statistical estimate from a small sample, and it gets more accurate the longer the window.
Block capture. Every share is checked against network difficulty too. When one clears it, the pool broadcasts the block immediately. Without the share pipeline, a winning hash would have no route to the network, and in Bitcoin a block that is not broadcast within seconds is usually a block someone else finds first.
Share difficulty vs. network difficulty
Share difficulty and network difficulty use the same scale, but a typical share target of 1,000 is about 127 billion times easier than the 127.45 T network target in effect on September 6, 2026.
Network difficulty is set by the protocol. Every 2,016 blocks, each node compares how long those blocks actually took with the 20,160 minutes they should have taken at 10 minutes each, and scales the difficulty by that ratio (capped at 4× in either direction). It rose 1.31% to 127.45 T at block 965,664 and has spent most of 2026 drifting down from the 148 T high set at the end of 2025. That retarget mechanism is what keeps block times near 10 minutes as hashrate comes and goes.
Share difficulty is set by the pool, per worker, and it is deliberately tiny. A 1 TH/s desktop board and a 90 TH/s heater both end up submitting at a comfortable cadence because the pool gives the faster miner a harder share target. The chart below puts share targets, expected best difficulties, the network target, and two real winning shares on one axis.
A winning share does not need to equal network difficulty; it needs to be at or above it. Block 957,382 was solved by a share at 294 T against a target of about 134 T. Overshooting earns nothing extra. It just means that hash was luckier than it needed to be.
Variable difficulty: why your share count drops after you connect
Vardiff is the pool’s automatic adjustment of your share difficulty so that every worker submits at roughly the same cadence, which is why a freshly connected miner floods the pool with shares for a minute or two and then settles down.
When a miner connects, the pool has no idea how fast it is, so it starts with a low share difficulty. A 1 TH/s miner at difficulty 64 submits about 218 shares a minute. That is more than the pool wants to process, so at the next interval it doubles the difficulty, then doubles it again, until the share rate lands near its target. From then on the difficulty only changes if the miner’s speed does.
Three consequences. First, the shares-per-minute number you saw in the first minute is not a benchmark; wait 15–30 minutes before judging anything. Second, an overclock that raises hashrate will, after a delay, raise share difficulty, so the share count may barely move even though the work did. Third, share counts across two miners on different difficulties tell you nothing about relative speed. The pool’s hashrate estimate already accounts for difficulty; use that instead.
How many shares should a miner submit per minute?
Expected shares per minute equal hashrate × 60 ÷ (share difficulty × 2³²), which at difficulty 1,000 works out to about 14 shares per minute for every 1 TH/s.
That shortcut, 14 × TH/s at difficulty 1,000, answers the question for any miner. Divide by 8 for difficulty 8,192, by 32 for 32,768, and so on. The chart shows the full curve for four hashrate tiers.
| Hashrate | Hardware class | Shares/min diff 1,000 |
Shares/min diff 8,192 |
|---|---|---|---|
| 0.5 TH/s | Early single-chip board | ~7 | ~0.9 |
| 1 TH/s | Single-chip desktop miner | ~14 | ~1.7 |
| 2 TH/s | Dual-chip desktop miner | ~28 | ~3.4 |
| 5 TH/s | Quad-chip desktop miner | ~70 | ~8.5 |
| 10 TH/s | Small home cluster | ~140 | ~17 |
| 40 TH/s | Home mining heater | ~560 | ~68 |
| 100 TH/s | Large heater or cluster | ~1,400 | ~170 |
Calculated expectations (hashrate × 60 ÷ (difficulty × 2³²)), September 2026. Per day at difficulty 1,000, multiply the first column by ~20,000. Your pool’s assigned share difficulty determines the actual rate. Stock hashrates across today’s home miners run from under 1 TH/s to 90 TH/s.
Shares arrive randomly, not on a metronome. Over one minute, a miner expecting 14 shares will commonly see anywhere from 7 to 21. Over an hour, the average is tight. This is Poisson statistics, and it is the same reason pool-side hashrate estimates need a long window to be accurate.
Accepted, rejected, and stale shares
An accepted share is valid and on time, a rejected share failed the pool’s validation, and a stale share was valid work submitted after a new block made the job obsolete; a healthy miner runs 99%+ accepted.
Accepted. Beat the share target, matched the current job, arrived on time. Counts toward your hashrate and is checked against network difficulty. This is normal operation.
Rejected. The pool could not validate it. Wasted work, no hashrate credit. Usual causes: a job mismatch after a reconnect, a corrupted packet, a duplicate share, or weak Wi-Fi.
Stale. Valid, but the block it was built on was already solved by someone else. Wasted work, and a small amount is unavoidable. Cause: latency between the pool’s new-job notice and your submission.
Classifications as reported by AxeOS-family firmware and most solo pools, September 2026. Some pools fold stale into rejected.
How much stale is unavoidable? The network finds a block every 600 seconds on average. If your round trip to the pool is 100 ms, any share found in the last 100 ms before a new block arrives is stale, which is 100 ms ÷ 600,000 ms ≈ 0.02% of shares. At a 500 ms round trip it is about 0.08%. Anything in the single digits of a percent is not latency; it is packet loss, reconnects, or a power problem, and the troubleshooting section covers those.
What best difficulty means, and what it does not
Best difficulty is the hardest share your miner has ever produced, so it shows how close you have come to a block, but it has zero predictive value because every hash is an independent draw.
There is a clean formula for what to expect. Each hash has a 1-in-(d × 2³²) chance of reaching difficulty d, so after H total hashes the expected best difficulty is about H ÷ 2³². A 1 TH/s miner performs 8.64 × 10¹⁶ hashes a day, so its expected best after one day is around 20 million, after a month around 600 million, after a year around 7.4 billion. That matches what customers report: single-chip miners commonly show a best in the low billions after a few weeks to months.
Now the part people get wrong. A miner at 3 G best difficulty is not “closer” to a block than one at 300 M. Both have identical odds on the next hash if their hashrates match. Best difficulty is a record of past luck, and past luck has no memory. The board that solved block 957,382 had been running for about eight hours; its best difficulty before the winning share was unremarkable.
What best difficulty is good for: a sanity check that the miner is working and a fun number to watch. If a miner’s all-time best sits at 5 M after a month at 1 TH/s, something is wrong with the pool connection or the hashrate readout, because the expectation is a hundred times higher.
Shares that became blocks: every documented find on open-source hardware
Seven Bitcoin blocks have been documented on open-source home mining hardware between July 2024 and July 2026, and each began as a routine share submission that happened to clear the full network target.
| Block · date | Hardware · hashrate | Reward |
|---|---|---|
| #853,742 Jul 24, 2024 |
Bitaxe Supra ~500 GH/s |
~3.15 BTC |
| #887,212 Mar 10, 2025 |
Bitaxe Ultra cluster ~3.3 TH/s |
~3.15 BTC |
| #889,975 Mar 2025 |
Bitaxe Gamma (stock) ~1.2 TH/s |
~3.15 BTC |
| #913,272 Sep 5, 2025 |
NerdQaxe++ ~4.8 TH/s |
~3.13 BTC |
| #920,440 Oct 27, 2025 |
6× NerdQaxe++ + Avalon ~130 TH/s |
~3.15 BTC |
| #924,569 Nov 21, 2025 |
6× Bitaxe Gamma 602 ~5.4 TH/s |
3.083 BTC |
| #957,382 Jul 9, 2026 |
Bitaxe Gamma ~995 GH/s |
3.138 BTC |
Compiled from Solo Satoshi’s block-find coverage and public block explorers, September 2026. Five were found through hosted solo pools, one through a self-hosted solo pool, and one through a pool where the miner built its own block template. Hashrates are operator-reported averages. Verify any block by height on mempool.space. Hardware names are historical record; several are earlier revisions than what ships today.
Three of these were Solo Satoshi customers. The six-unit cluster behind block 920,440 was pointed at solo pool software running on the owner’s own node, which means the block template, the coinbase, and the broadcast all happened on hardware in his house. A single NerdQaxe++ had found block 913,272 a few weeks earlier, and the six-unit Gamma setup behind block 924,569 submitted its winning share at 221.39 T to a hosted solo pool. Each of these Bitaxe block finds is verifiable on-chain by height.
What are the odds a share becomes a block?
At the September 6, 2026 difficulty of 127.45 T, a 1 TH/s miner has roughly a 1-in-6.3-million chance per day of solving a block, an expected wait of about 17,000 years, and the odds scale linearly with hashrate.
The math: expected hashes per block = difficulty × 2³² ≈ 5.47 × 10²³. Divide by your hashrate for expected seconds. Multiply your daily hashes by the inverse for daily odds. Ten 1 TH/s boards, or one 10 TH/s device, cut the expected wait to about 1,700 years and raise daily odds to 1 in 630,000.
| Hashrate | Expected wait | Daily odds | Chance in 20 yrs |
|---|---|---|---|
| 1 TH/s | ~17,300 yrs | 1 in 6.3 M | 0.12% |
| 5 TH/s | ~3,500 yrs | 1 in 1.3 M | 0.57% |
| 10 TH/s | ~1,700 yrs | 1 in 630 K | 1.15% |
| 40 TH/s | ~430 yrs | 1 in 158 K | 4.5% |
| 100 TH/s | ~170 yrs | 1 in 63 K | 10.9% |
| 200 TH/s | ~87 yrs | 1 in 32 K | 20.6% |
Calculated at 127.45 T (block 965,664, Sept 6, 2026), assuming difficulty held constant. Chance within t years = 1 − e^(−t ÷ expected years); the one-year figure is one twentieth of the 20-year column. Difficulty will change, so treat these as order-of-magnitude figures.
Difficulty moves. It fell 10% in June 2026 and rose 1.3% in September; your odds move inversely with it, so your own odds and electricity cost are worth running against live difficulty rather than the snapshot here.
Solo mining is a lottery ticket that never expires and costs a single-chip miner about $1.50 a month in electricity. It is not an income plan, and no one should present it as one.
Expected time vs. what actually happens
“Expected 17,000 years” does not mean “wait 17,000 years”; the time to a block follows an exponential distribution, so most miners never see one and a few see one almost immediately, which is exactly how seven home miners found blocks in two years.
Three things follow from the exponential shape:
- No memory. A miner that has run for five years without a block has the same odds tomorrow as one switched on today. Time served buys nothing.
- The median is shorter than the mean. Half of all blocks are found in less than 69% of the expected time (ln 2 ≈ 0.69). “Early” finds are normal, not anomalies.
- Population matters. With tens of thousands of open-source home miners online, the community’s combined hashrate is what produces several finds a year, even though each individual’s chance is tiny. Adding a miner raises your share of that outcome in exact proportion to hashrate.
How to monitor your shares: step by step
You can watch shares in three places: the miner’s own dashboard, your pool’s worker page, and a fleet monitor if you run more than one device.
- Open the miner’s dashboard. On AxeOS-family firmware, type the IP shown on the device’s screen into a browser on the same network. You will see hashrate, accepted, rejected, best difficulty (session and all-time), and ASIC temperature.
- Check the pool side. Most solo pools have a stats page where you enter your Bitcoin payout address and see every worker on that address: hashrate, session best difficulty, and uptime. Pool-side hashrate lags the device by 10–15 minutes and is an estimate.
- Compare the two numbers. The device and the pool should agree within roughly 10% over an hour. If the pool reads far lower, shares are being lost in transit. That is a network issue, not a chip issue.
- Watch the reject percentage, not the count. Rejected ÷ (accepted + rejected). Under 1% is excellent, under 2% is fine, above that needs attention.
- Sanity-check best difficulty against runtime. Expected best ≈ hashrate × seconds ÷ 2³². A 1 TH/s miner should be in the tens of millions after a day and the billions after a few months. Far below that means the miner is not hashing as reported.
- Aggregate a fleet. A fleet monitor such as Hashwatcher pulls every AxeOS-compatible miner into one screen so you can spot the unit that stopped submitting. Every submission also appears line by line in the mining log if you want to go deeper than the dashboard.
How to fix rejected and stale shares
Most reject-rate problems on a Wi-Fi miner trace to the 2.4 GHz link or pool latency, and the fix is usually moving the miner, changing the channel, or choosing a closer pool server.
- Rejects arrive in bursts, then go quiet. Wi-Fi dropouts and reconnects; shares for the old session get “job not found.” Check RSSI on the dashboard and your router logs. Move closer, switch to a clear 2.4 GHz channel (1, 6, or 11), or add an access point near the miner.
- Steady 2–5% stale. High latency to the pool. Ping the pool host and compare regional servers. Use the nearest one; several solo pools run regional endpoints.
- Rejects spike after a firmware update. Stratum reconnect bug in an older release. Update to the latest firmware through the dashboard, or by flashing the miner.
- Rejects plus random reboots. Power supply sagging under load. Check input voltage on the dashboard and the PSU rating against actual draw. Use a supply rated well above your settings and keep continuous draw under 80% of its rating; overclocks need more than stock.
- “Duplicate share” errors. Two workers in the same extranonce space, or a proxy misconfiguration. Give each miner a unique worker name after the address (
address.worker1). - Pool hashrate far below device hashrate, few rejects. Shares lost silently before reaching the pool. Compare the accepted count to the expectation (14/min per TH/s at diff 1,000) and apply the Wi-Fi fixes above; a wired access point beside the miner is the reliable cure.
- Device hashrate and temps normal, rejects high. The ASIC is fine. The problem is everywhere between the board and the pool. Do not touch frequency or voltage.
Symptom-to-fix list compiled from Solo Satoshi support tickets, September 2026.
Pool rejects are a different thing from the dashboard’s hashrate error percentage, which reports the ASIC’s internal results, not the pool’s verdict.
What a share is worth: solo mining vs. pool mining
In pool mining every accepted share earns a proportional slice of each block the pool finds; in solo mining shares earn nothing and the full block reward goes to whoever submits the winning share.
Pools use share counts as the accounting unit, and there are three common schemes:
| Scheme | How shares pay | Variance on | Fee |
|---|---|---|---|
| PPS | Fixed amount per share, block or no block | Pool | Higher |
| PPLNS | Split of real blocks by recent shares | Miners, partly | Lower |
| FPPS | PPS plus a share of tx fees | Pool | Higher |
| Solo | Nothing per share; full block to finder | Miner, fully | 0–2% |
Reward schemes as commonly implemented, September 2026. Individual pools vary.
Under any scheme, a 1 TH/s miner earns on the order of a few cents a day before fees and electricity when pooled. Solo, it earns nothing until a share clears network difficulty and then keeps 3.125 BTC plus fees. The expected value per hash is the same in both cases; that is a mathematical identity, not a marketing claim. What differs is whether you receive it in a trickle or, probably never, in one lump. That is why solo is often called lottery mining.
Some firmware can split hashrate between a solo pool and a payout pool at the same time, a reasonable middle path if you want a few sats trickling in alongside the lottery ticket. A solo miner and a pooled miner run the same hardware and the same firmware; the choice is about payout shape, and it sits alongside hosted and cloud mining in the wider landscape of Bitcoin mining.
Advanced: self-hosted pools, Stratum v2, and DATUM
Running your own pool software on your own node means you build the block template yourself, which changes who controls the coinbase and the transaction selection but does not change how shares work.
Self-hosted solo pool. Open-source solo pool software runs as a one-click app on most home server platforms. Your miner points at your server; your server points at your node. The template comes from your mempool, the coinbase carries your address, and if a share wins, your node broadcasts the block. The block 920,440 finder ran exactly this kind of self-hosted setup on his own node. The trade-off is that you are responsible for uptime: if your server or node is down, your miner has no jobs.
Stratum v2. A newer protocol that encrypts the miner-pool connection, uses a compact binary format, and optionally lets miners choose their own transactions (job negotiation). Shares are still hashes below a target; only the wrapper changed. Support in home-miner firmware is still limited as of September 2026.
DATUM. A protocol that lets miners build their own block templates from their own node while still being paid by a pool. The NerdQaxe++ that found block 913,272 was mining this way. Again, the share mechanism is unchanged; what moved is template construction from the pool to the miner, and with it a piece of decision-making that used to sit only with pools.
The common thread: every one of these changes who builds the block and who is trusted. None of them changes what a share is. If you understand the two-target model in this article, you understand shares on every current protocol.
Bottom line
A share is a hash that cleared the easy bar. A block is a share that also cleared the hard one. Everything else in mining, from vardiff to pool payouts to the numbers on your dashboard, is bookkeeping built on that one distinction.
If you are solo mining, shares are your instrument panel, not your paycheck. Watch the accepted count to confirm the miner is alive, keep rejects under 2%, sanity-check best difficulty against runtime, and ignore it as a predictor. If you want steady sats, point the same hardware at a payout pool and let shares become the accounting unit instead.
The odds are what they are: 1 TH/s is a 1-in-6.3-million daily ticket at today’s difficulty, and adding hashrate scales that linearly. Whatever you run, from a palm-sized single-chip board to a whole-room mining heater, the share pipeline is identical. If you are choosing hardware, every current model’s stock hashrate and power draw sit side by side across the Bitcoin miners we stock.
Related reading
- What is Bitaxe?
- AxeOS Explained
- Understanding Bitcoin Mining Network Difficulty
- Has Bitaxe Found a Block?
- Hashrate Error Percentage Explained
- Bitaxe Setup Guide
- Understanding Mining Pools
- Choosing a Solo Mining Pool
- Understanding the Bitaxe Mining Log
- Bitcoin Lottery Mining: Riding Solo
Do mining shares earn Bitcoin?
Is a Bitcoin mining share the same as a block?
How many shares does a 1 TH/s miner submit per day?
What is a good rejected share rate?
Does a high best difficulty mean I am close to finding a block?
Why did my share count drop a few minutes after I connected?
What is the difference between a hosted solo pool and a self-hosted one?
Why is my pool hashrate lower than my miner's dashboard hashrate?
Guy Chouinard
I really learned a lot from reading this, the support you provide to your customers is nothing short of outstanding. Thank you for this and AA your contributions to the hobby mining community.