-
Notifications
You must be signed in to change notification settings - Fork 35
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
Worker Specific Hashrate Tracking Extension #113
base: main
Are you sure you want to change the base?
Worker Specific Hashrate Tracking Extension #113
Conversation
81852c2
to
1f5150f
Compare
After yesterday's call, I noticed that there were some misunderstandings about this PR. So I just pushed a new commit to clarify this point of discussion. Please @Fi3 @TheBlueMatt review the last commit: 9260a15 |
9260a15
to
445048c
Compare
03-Protocol-Overview.md
Outdated
### Usage Guidelines | ||
|
||
- **TLV fields MUST be placed at the end of the message payload.** This ensures compatibility with existing Stratum V2 messages. | ||
- **Order of TLV fields is not significant.** Since all extensions are negotiated beforehand, the recipient MUST scan for TLV fields using their Type identifiers rather than relying on a fixed order. |
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 would add that in the extension order matter. If an extension add more the one field you will have first field of ext A is T1 second of ext A is T2 ecc ecc
I think that is better to specify such thing here rather than in every extension to avoid confusion.
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.
Good point, I will add this clarification in a new commit.
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.
This PR adds an extension to directly send a
user_identity
field inside aSubmitSharesExtended
. Theuser_identity
field is limited to a maximum of 32 bytes-length to not increase too much the additional bandwidth consumption for extended shares submissions.This PR follows #112.