223 / 736SHARE

Mining Share

How miners demonstrate their work to a pool

Petr connects his mining machine to a pool, a service that brings miners’ work together. Accepted shares accumulate on the screen, but nothing new appears in his wallet yet. That is not a contradiction. A share first demonstrates work; calculating and sending a reward are later steps. Without these ongoing proofs, a pool would struggle to assess each miner’s contribution when finding an actual block can take a long time.

A Mining Share is a mining calculation result that meets the pool’s requirement for a particular job. The pool uses these verifiable samples to estimate work contributed. The requirement is normally easier than that for a valid Bitcoin block, so most shares are not new blocks.

Petr’s machine makes an enormous number of attempts. The pool does not need a message for each one; it receives selected results meeting a predetermined requirement. It can verify them and statistically estimate work from their frequency and difficulty. A Mining Share is therefore neither part of an unfinished block nor a transferable stake in bitcoin. It is not a transaction recorded on the blockchain either: that is the public history of Bitcoin transactions arranged in linked blocks. The share lets the miner demonstrate a contribution of computational work to the pool. [1]

Mining seeks a hash—a calculation result interpreted as a number—that is no higher than a specified target. A pool normally sets a numerically higher target than the network: more results pass, making it easier. A result good enough for the pool usually falls short of a block. By chance, some also meet the stricter network target. They can lead to a new block if the entire block meets the other rules too. The pool does not relax Bitcoin’s rules; it sets its own threshold for ongoing evidence of work. [1]

Petr does not have to assemble these messages manually; mining software does it. Stratum V2 is a protocol, a set of communication rules between equipment and a pool. Its SubmitSharesStandard message includes job_id to identify the job, nonce as a value varied during the search, ntime for the timestamp in the block header and version for the version of the header, the block’s compact data section. It also identifies the communication channel. The pool needs this context to verify the calculation; a nonce without its correct job is not a standalone proof of work. [2]

Imagine Petr comparing machines assigned jobs of different difficulty. Difficulty acts as a weight here: a result meeting a stricter requirement is credited as more work. Using the same scale for both, two accepted submissions at difficulty 1024 carry the same total weight as one at difficulty 2048. The message count differs, but the credited amount of work is the same. Even this sum is not an exact record of all calculations actually performed: individual successes are random. Check whether a counter labelled shares reports accepted results or their weight after conversion to a common scale. [3]

A pool sometimes acknowledges several submissions at once. Stratum V2 uses the SubmitShares.Success response for this. The new_submits_accepted_count field counts newly acknowledged submissions, while new_shares_sum adds the difficulties of their jobs. The first counts results; the second counts their weight. Both refer to the batch currently being acknowledged, not automatically to the miner’s lifetime totals. When reading the protocol, there is therefore no reason to expect a separate acknowledgement for every result sent. [2]

Petr’s machine may report that it sent a result while the pool is still validating it. Stratum V2 uses SubmitShares.Error for an incorrect submission; its sequence_number identifies which submission the error concerns. If validation cannot happen immediately, the error response can arrive later. Distinguish submitted results from confirmed accepted ones, and watch for rejections too. A rising local submission counter alone does not prove that the pool credited everything. [2]

Confirmed work enters the particular pool’s reward rules. For example, Braiins’ FPPS, Full Pay Per Share, calculates rewards from submitted work and network data, including difficulty and block rewards; it also includes a transaction-fee component. The pool deducts its fee, and transfers follow payout settings. A share acknowledgement does not itself send BTC (bitcoin) to a wallet. Petr therefore monitors accepted work, calculated rewards and actual payouts separately. [4]

A share counter may resemble download progress, but mining does not work that way. Shares and blocks arise from searching for sufficiently low hashes, with random outcomes. More demonstrated work provides a better statistical basis for estimating hashrate, not certainty of another success. A long series of accepted shares does not guarantee a block on the next attempt. The counter tells Petr about ongoing work and its acceptance, not that only the final piece of a block remains. [3]

For the clearest picture, read this entry together with Mining Pool, Share Difficulty, Proof of Work, Mining Target, Bitcoin. The reverse links also lead from ASIC Miner, Mining Pool, Braiins Pool, Stratum V1.

DOC · 001Bitcoin Developer Guide — Pool miningDocumentation DOC · 002Stratum V2 — Mining ProtocolSpecification DOC · 003Braiins Academy — Pool FAQDocumentation DOC · 004Braiins Academy — Rewards and payoutsDocumentation
Revised: Source-first · No investment advice