Difficulty Adjustment for Jobs

[plebhash]

During our call today (April 30, 2024) we had some discussions around strategies for setting the Difficulty Target on Jobs.

This github discussion could be a good way to write down some of those ideas for future reference.

[plebhash]

@Fi3 a few questions:

• could you provide a high level description of how the translator proxy currently implements Difficulty Adjustment over SV1?
• what lessons can we take from that, and how how can we leverage SV2 Protocol Extensions to make that process more efficient?
• is there something like this implemented for SV2 Pool and SV2 Proxy on our SRI roles?

[Fi3]

I think that @GitGab19 wrote that part, maybe is more suited to answer than me

[GitGab19]

The difficulty adjustment in translator is implemented in a way to reach the target number of shares_per_minute specified in translator config. Every time a new job is sent downstream, translator tries to update the difficulty through this function.
Inside that, it enters in the core of the difficulty adjustment here:

stratum/roles/translator/src/lib/downstream_sv1/diff_management.rs

Line 199 in 24b8b1d

pub fn update_miner_hashrate(

Let me know if you need more granularity about the update_miner_hashrate explanation!

[plebhash]

I have another question from a more theoretical perspective. I've been reading the Rosenfeld paper.

The paper seems to set the definition of a share around a fixed difficulty target, which is the minimum possible value (1).

To determine the amount of work done for the pool, users find and submit shares, hashes of a block header which are low enough to have made a block if the difficulty was 1.

The paper goes on to explain multiple payout schemes based on this definition, including the most popular ones used in the industry nowadays (PPS, PPLNS).

However, that doesn't seem sustainable. Maybe at the time when the paper was written (2011), it was ok for multiple miners to be sending shares of difficulty 1 from their CPUs and GPUs to a pool. But nowadays, with ASIC farms, this would basically be a DDoS attack against the pool, because each miner would be submitting an astronomically high number of shares per second.

Also, as already discussed above, our Proxy implementations perform a difficulty adjustment algorithm for each miner, so that they only submit shares above an optimal difficulty threshold.

So my question is: how do payout schemes like PPLNS and Double Geometric Method take this per-miner difficulty variability into account?
E.g.: A share submitted under a higher difficulty must be valued more than a share submitted under a lower difficulty.

[GitGab19]

Nowadays every pool sets a difficulty (sometimes defined in papers ad pDiff) which is higher than 1, as suggested by your comment.
For what regards payout schemes, I'm pretty sure that you can find the answer at chapter 7.5 of Rosenfeld paper