Stale Rate

A pool is a service that distributes work among miners. When the network finds a new block, miners usually need to start building on it. A result calculated from the previous job is no longer useful for the new work. Stratum V2, a protocol for mining-device communication, handles this with SetNewPrevHash: the device starts looking for a block that builds on the newly specified block. Of the jobs prepared earlier, only the one named by the job identifier job_id remains valid. When investigating, Petra therefore checks which job was valid, not just when the result was sent. [1]

In a simple example, Petra submits 100 results at equal difficulty. The pool accepts 98, rejects 1 as stale and rejects 1 for another reason. Rejected stale results account for 1%; all rejections together account for 2%. F2Pool calls all rejected submissions divided by all submissions the rejection rate. Stale is only part of that total in our example. The numbers explain the calculation, not an acceptable operating threshold; a dashboard using different categories may mean something else. [2]

Share difficulty determines how demanding a result the device must submit. Braiins accounts for a result at difficulty d as d basic work units. Imagine one stale share at difficulty 1 and one accepted share at difficulty 9. Counting submissions gives 50%; weighting the work gives 10%. Neither calculation is inherently wrong, but they answer different questions. Petra therefore uses the same unit on both sides of the fraction when comparing results and checks that the difficulty convention is the same. [3]

F2Pool’s documentation distinguishes a category called Staled, which earns rewards, from rejected stale shares, which do not. The label alone therefore does not say whether Petra has lost money. This policy cannot be assumed for every pool: the particular service’s rules and actual accounting matter. When comparing providers, Petra first establishes which category the results belong to. Only then can she estimate their effect on income. [2]

When reading an operating log, it is easy to miss that Stratum V2 can acknowledge multiple submissions in one SubmitShares.Success message. The new_submits_accepted_count field gives their newly acknowledged count, while new_shares_sum adds their difficulties. Counting server responses therefore does not count accepted shares. For a rejection, SubmitShares.Error includes sequence_number, the submission identifier, and error_code, the reason for the error. Without this distinction, Petra might mistake every error for late work. [1]

News of a new block must first travel through the computers that verify Bitcoin. BIP152 describes Compact Block Relay, a more bandwidth-efficient way to transfer blocks between nodes in the P2P network, meaning directly connected peers. Less data can reduce transmission delay. This concerns block propagation, however, not pool share accounting. The proportion of blocks left outside the main chain therefore does not measure late results from Petra’s machine. [4]

Braiins offers work statistics over different periods: shares_5m (over the last 5 minutes), shares_60m (over the last 60 minutes) and shares_24h (over the last 24 hours). Petra cannot divide late results from a short interval by a whole day’s work and compare that figure with another machine’s hourly statistics. Both parts of the calculation must cover the same period and devices. If no submissions were observed, the ratio is undefined; it is not a measured 0% loss. Neither a monitoring gap nor a missing response alone proves that a result was stale. [5]

Petra starts with job changes, rejection reasons and connection conditions over the same period. F2Pool mentions network conditions for stale results. Other rejections can arise from errors in the firmware, the software that controls the machine, or excessive overclocking: raising the chips’ operating frequency to try to perform more calculations. Braiins suggests ping, a simple test of whether the server responds to network probes. A successful reply does not confirm correct mining or credited rewards. A lower overall percentage alone does not prove the cause was fixed. The aim is to identify what changed and track the particular error under comparable conditions. [2] [6]