-
Notifications
You must be signed in to change notification settings - Fork 37
upgrade Job Declaration and Mining Protocols #121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
d7dbd0b
to
22fb563
Compare
c3baaca
to
5583c11
Compare
I don't think it's wise to have two messages in the spec called |
I don't think it's possible to unify them, as one is meant for TP and the other for JDS (and each needs different parts of the solution) I'm not opposed to renaming either one of them or both, but it would be good to get input from @Fi3 and @TheBlueMatt on this |
@@ -75,45 +125,40 @@ Notably, if the pool intends to change the space it requires for coinbase transa | |||
| request_id | U32 | Unique identifier for pairing the response | | |||
| mining_job_token | B0_255 | Token that makes the client eligible for committing a mining job for approval/transaction declaration or for identifying custom mining job on mining connection. | | |||
| coinbase_output_max_additional_size | U32 | The maximum additional serialized bytes which the pool will add in coinbase transaction outputs. See discussion in the Template Distribution Protocol's CoinbaseOutputDataSize message for more details. | | |||
| async_mining_allowed | BOOL | If true, the mining_job_token can be used immediately on a mining connection in the SetCustomMiningJob message, even before DeclareMiningJob and DeclareMiningJob.Success messages have been sent and received. If false, Job Declarator MUST use this token for DeclareMiningJob only. <br>This MUST be true when SetupConnection.flags had REQUIRES_ASYNC_JOB_MINING set. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how the upstream communicate if the token is for coinbase-only mode or for full-template mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by simply allowing the connection to be established or not
when JDC sends SetupConnection
, the DECLARE_TX_DATA
bit flag is used to signal that it consents to revealing the txs... then it's up to JDS to decide whether this is ok or not
so we have 4 possible scenarios:
JDS allows Coinbase-only mode | JDS does NOT allow Coinbase-only mode | |
---|---|---|
JDC sets DECLARE_TX_DATA |
SetupConnection.Success |
SetupConnection.Success |
JDC does NOT set DECLARE_TX_DATA |
SetupConnection.Success |
SetupConnection.Error (unsupported-feature-flags ) |
do you feel this still leaves room for unspecified scenarios?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is heavily based on the assumption that JDS will operate EITHER under Coinbase-only OR Full-Template, but not BOTH at the same time.
If we want to allow for JDS to operate under both at the same time, then I see how DECLARE_TX_DATA
is not sufficient, as JDC wouldn't know under which mode the token is supposed to be used.
So I guess the question is: does this scenario make sense? Can JDS ever allow for both Coinbase-only and Full-Template at the same time? TBH it doesn't really make much sense in my head, but maybe I have some blindspot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GitGab19 what are your thoughts here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think it doesn't make too much sense, but maybe @Fi3 meant something different so it's better to get clarifications from him on this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to allow for JDS to operate under both at the same time, then I see how DECLARE_TX_DATA is not sufficient, as JDC wouldn't know under which mode the token is supposed to be used.
So I guess the question is: does this scenario make sense? Can JDS ever allow for both Coinbase-only and Full-Template at the same time? TBH it doesn't really make much sense in my head, but maybe I have some blindspot.
I guess I should retract what I said here.
it doesn't matter that JDS supports both modes.
if JDC sends SetupConnection
with DECLARE_TX_DATA
bit enabled, then it assumes the connection is operating under Full Template mode (and all tokens are allocated are allocated with that in mind)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep before it was a token property so you could mix them but I guess it make more sense to define it connectionwise.
251067a
to
b16de1e
Compare
make sense |
Co-authored-by: Gabriele Vernetti <[email protected]>
these description fields were changed via 9b0e40b and it's an obvious mistake
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK on my end 👍
Let's maybe wait a bit for @Fi3 input on the last opened discussion.
After that, it's good to go imo.
7e20c54
to
9b41e0e
Compare
close #120
changes:
SubmitSolution
toPushSolution
(to avoid confusion with TDPSubmitSolution
)prev_hash
field toDeclareMiningJob
messageversion
field toPushSolution
message (fkaSubmitSolution
)nbits
field ofPushSolution
message (fkaSubmitSolution
)extranonce_size
,min_ntime
andversion
fields fromSetCustomMiningJob
messagefor easier review, I recommend this Markdown rendering on my fork