# Why does the Stratum protocol use a Share Difficulty of 2^32?

In the comments below his answer to my recent question about Network Difficulty, Pieter noted that Stratum Share Difficulty is an entirely separate concept. See https://bitcoin.stackexchange.com/a/121133/142060 where he states:

"Inside the Stratum protocol used for pool mining there is also a notion of (share) difficulty, however it corresponds to exactly 2^32 hashes per block (so it differs from difficulty as used by the rest of the ecosystem)"

To summarize, this means that statistically, mining 1 pool share requires computing 2^32 hashes, on average. 2^32 equates to 4294967296.

By comparison, Network Difficulty at the first epoch (aka Difficulty 1) is defined such that out of 2^256 possible hashes, exactly 0xffff * 2^208 + 1 of them would mine a valid block. (0xffff * 2^208 + 1) / 2^256 equates to 1/4295032833.000015.

Is it pure coincidence that 2^32 (4294967296) is so close to the reciprocal of the Difficulty 1 ratio of valid-to-total hashes (4295032833.000015)? Or was 2^32 chosen as a convenient approximation of this number?

Here is some Python to illustrate:

``````# Share Difficulty
share_difficulty = pow(2, 32)

# Network Difficulty 1
possible_hashes = pow(2, 256)
valid_hashes = int(b'0xffff', 16) * pow(2, 208) + 1
valid_hash_ratio = valid_hashes / possible_hashes

print(1 / valid_hash_ratio)
# 4295032833.000015

print(1 / valid_hash_ratio - share_difficulty)
# 65537.00001525879
``````

If my theory of 2^32 being an approximation is not correct, does anyone know why it was chosen as Share Difficulty within the Stratum protocol?

Thank you

bitcoin block headers have a field called `Bits` where the difficulty target is encoded as a 32 bits integer

the lower the target, the more difficult it is to generate a block.

mining shares are regular bitcoin blocks with higher targets (or in other words, they are "weaker" blocks)

the pool needs to establish some kind of "tuning" between what constitutes a minimally accepted amount of work to cross over a payout threshold

that is inherent to the engineering tradeoffs to the pool's architectural design and the finite infrastructure it's running on

in order to define what constitutes minimally acceptable work threshold, there's two fundamental variables at play:

• rate of share submissions
• share difficulty (how much work each share represents)

if a miner submits shares at a high rate (relative to connection bandwidth with the pool), but the share difficulty is too small (targets are too high, blocks are too weak), the pool could rightfully label these submissions as spam

hopefully, decentralization will lower this bar, and we will have smaller thresholds allowing for smaller miners to participate in PoW without having to resort to "lottery games" to fulfill their ideological motivations

in summary, a mining protocol such as Stratum needs to have some kind of "unit" that represents some minimal amount of work (let's call it `minTarget`). This unit is represented as a difficulty target, which needs to be relatively high number between `0x00000000` and `0xFFFFFFFF`.

since we are encoding difficulty targets with 32 bits, we have a few options:

• `0b11111111111111111111111111111111`: human friendly, but inefficient because results in high traffic for share submission, while past (and current) centralized pool architectures do not have bandwidth nor computational resources to account for the amount of shares that would be submitted by each miner.
• `0b10000000000000000000000000000000`: a trade-off for a human-friendly number that still results in a reasonably efficient bandwidth consumption for share submission

so while using Stratum, the miner can configure their machines in a way that it will only submit a share if it is above `N * minTarget`.

on the other hand, pools could also choose to refuse shares below `M * minTarget` because those would consume excessive infrastructure resources (e.g.: bandwidth for share submission, or computation/memory for share accounting) without a meaningful PoW contribution.

SV2 Translator Proxies have a configuration parameter where the miner can throttle the total amount of shares (coming from their SV1 machines) that are going to be submitted upstream towards the pool.

that way, even if the farm has many small machines (e.g.: Bitaxe), but its aggregate hashrate is above the pool's accepted minimum, their shares will be more easily accepted and fairly accounted for

• Thanks @plebhash for the info. The more I've learned on this subject (outside this thread), the more I am convinced that share difficulty can be set arbitrarily by the pool... but that it is commonly set as some multiple of 2^32. If anyone can point to where share difficulty is set in the stratum V1 codebase, or in an open source mining pool implementation, that would help to validate. Commented Jan 29 at 14:02
• I get what you mean when you say it's an arbitrary decision, it does seem like that at a first glance. But calling it arbitrary could give us the wrong idea, because in the end of the day, this is an engineering-driven design decision. Pools should choose the minimum share difficulty as a function of the total amount of hashrate it aims to accomodate vs the available infrastructure resources. Saying it's 100% arbitrary could lead to inefficient choices (e.g.: excessive bandwidth consumption for share submission, or excessive computation/memory consumption for share accounting) Commented Jan 29 at 20:56
• unfortunately I'm not familiar with the SV1 codebase, so I cannot help you with that Commented Jan 29 at 20:57
• I do not see what this answer has to do with the question. The stratum difficulty is not a 32-bit integer at all, it's a JSON floating-point number. The question is why that represents a multiple of 2^32 hashes rather than difficulty used elsewhere in the Bitcoin ecosystem (where it represents a multiple of 2^48/65535 hashes). Commented Jan 29 at 21:06