Docs: good implementation guidelines

[plebhash]

today on the call @Fi3 suggested that we create a new doc file with good implementation guidelines

that would account for every implementation aspect that:

• is not explicitly defined by the SV2 specs
• maybe is implemented on SRI roles (maybe not)

[plebhash]

the first guideline:

pools shouldn't set difficulty targets for downstream channels based solely on the hashrate that the downstream reports, because the downsteram could simply lie in order to get a low difficulty target and later send too many shares (which technically constitutes a form of spam).

Instead, the pool should collect shares and slowly increase the difficulty target, just like it is done on the translator proxy implementation.

[plebhash]

@Fi3 do you have more ideas that could be added to the list here?

[pavlenex]

Instead, the pool should collect shares and slowly increase the difficulty target, just like it is done on the translator proxy implementation.

Is there a reason why this is doc and not actual pool to-do in SRI?

[Fi3]

This is intended to be a doc of best-practice/guidelines that a pool implementer should follow. So things that not fit into specification but still important.

[Fi3]

Like for example that thing about the token that you asked me before

[pavlenex]

Oh no, I understand that part, but to me this seems like a no-brainer that should be added to pool-role in SRI?

[Fi3]

Considering what SRI pool is:

• a way to test the stack
• a way to show that sv2 spec can be implemented

And considering that pool is nowhere near being prod ready. This thing is for sure a nice to have. But given the resource that we have I don't think that we should do it now.

[pavlenex]

Yeah I am not implying this should be done now, but to me, if there's a feature that can be added to the pool and it's logical, there's no reason not to log it. I am confident more and more implementors will be interested in our Pool, and we shouldn't just treat it as a way to test a stack, it should allow basic functionality and be extendable by anyone willing to implement anything beyond basics.

[Fi3]

Agree that we have to log it I wasnt' saying the contrary. About:

and we shouldn't just treat it as a way to test a stack, it should allow basic functionality and be extendable by anyone willing to implement anything beyond basics.

This is quite a big project right now make more sense focus on the libraries, that can be used to build the pool.