[WIP] cleanup and update JD Protocol specs #104
Conversation
plebhash
force-pushed
the
update-jd-protocol
branch
4 times, most recently
from
52045c8
to
9e628b0
Compare
|
|
||
| | Field Name | Data Type | Description | | ||
| | -------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | request_id | U32 | Identifier of the original request | | ||
| | new_mining_job_token | B0_255 | Unique identifier provided by the pool of the job that the Job Declarator has declared with the pool. It MAY be the same token as DeclareMiningJob::mining_job_token if the pool allows to start mining on not yet declared job. If the token is different from the one in the corresponding DeclareMiningJob message (irrespective of if the client is already mining using the original token), the client MUST send a SetCustomMiningJob message on each Mining Protocol client which wishes to mine using the declared job. | | ||
|
|
||
| ### 6.1.6 `DeclareMiningJob.Error` (Server->Client) | ||
| ### 6.3.6 `DeclareMiningJob.Error` (Server->Client) | ||
|
|
There was a problem hiding this comment.
Worth writing explicitly here that the client MUST switch to a fallback pool/solo mining at this point?
There was a problem hiding this comment.
well, I guess it is worth pointing that out, but we should avoid generalizations
what if there was something wrong with DeclareMiningJob?
it should be stressed that this should trigger fallback only if this is a response to a DeclareMiningJob that JDC deems to be valid
There was a problem hiding this comment.
I mean in general across all of Sv2 if a pool is rejecting the work you're doing, you should probably fall back to solo mining (or a fallback pool). Even if you're the one doing something wrong, you might as well try a fallback pool or solo mining because the thing you're doing wrong might still allow you to get credit for your work with one of those. Continuing to mine when you know you aren't getting credit is obviously not okay :).
I think its just relevant to note here explicitly to run off the "well, the pool rejected it, so I mined with their work" logic that one might read into these Error messages.
There was a problem hiding this comment.
I see your point.
I pushed some updates addressing all the comments, including this one.
There was a problem hiding this comment.
IMO the main issue here is that we have some *.Error that are used only for logging like the above, and other ones that are used for recoverable errors (see submitshare ecc ecc). What I did in the share accounting ext for example is to use one general error used in response to every irrecoverable error used for logging, and specific message for cases that are supposed to be recoverable (you should not close the connection)
https://github.com/demand-open-source/share-accounting-ext/blob/master/extension.md#13-error
I would not change the spec at this point ofc. But I would make vary clear which are the errors that are there only fro logging purposes (log it and close the connection) and which not.
plebhash
force-pushed
the
update-jd-protocol
branch
3 times, most recently
from
c9dec9e
to
ec313a2
Compare
plebhash
force-pushed
the
update-jd-protocol
branch
2 times, most recently
from
125350e
to
71a5c44
Compare
plebhash
force-pushed
the
update-jd-protocol
branch
from
71a5c44
to
7a23e97
Compare
close #77