Skip to content

Commit 81852c2

Browse files
GitGab19GitGab19
committed
worker specific hashrate tracking extension
1 parent 02b0963 commit 81852c2

File tree

2 files changed

+90
-3
lines changed

2 files changed

+90
-3
lines changed

‎09-Extensions.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
# 9. Extensions
22

33
There are not yet any defined extensions.
4-
| Extenstion Type | Extension Name | Description / BIP |
5-
| -------------------- | -------------- | ---------------------------------------------------------------------------- |
6-
| (no channel_msg bit) | | |
4+
| Extension Type | Extension Name | Description / BIP |
5+
| -------------- |-----------------------------------|----------------------------------------------------------------------|
6+
| 0x0001 | Worker Specific Hashrate Tracking | Definition [here](./extensions/worker-specific-hashrate-tracking.md) |

‎extensions/worker-specific-hashrate-tracking.md

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
# Stratum V2 Extension: Worker-Specific Hashrate Tracking
2+
3+
## 0. Abstract
4+
5+
This document proposes a Stratum V2 extension to enable mining pools to track individual workers (`user_identity`) within extended channels. By extending the `SubmitSharesExtended` message to include a mandatory `user_identity` field (up to 32 bytes), pools can track worker-specific hashrate while preserving the existing channel structure.
6+
7+
Terms like "MUST," "MUST NOT," "REQUIRED," etc., follow RFC2119 standards.
8+
9+
---
10+
11+
## 1. Extension Overview
12+
13+
This extension modifies the existing `SubmitSharesExtended` message by adding a mandatory `user_identity` field. Clients must populate this field to allow the pool to track individual worker performance.
14+
15+
### 1.1 Activate Extension
16+
17+
To enable the extension, the client MUST send a `RequestExtensions` message immediately after the `SetupConnection` message. This message includes a list of requested extensions by their `U32` identifiers. If the pool supports the requested extensions, it responds with a `RequestExtensions.Success` message containing the list of supported `U32` extension identifiers. If the pool does not support any of the requested extensions, it responds with a `RequestExtensions.Error` message.
18+
19+
#### Message Exchange Example
20+
21+
1. **Connection Setup**:
22+
```
23+
Client --- SetupConnection (connection details) ---> Server
24+
Client <--- SetupConnection.Success (connection accepted) ---- Server
25+
```
26+
27+
2. **Extension Request**:
28+
```
29+
Client --- RequestExtensions [0x0002] ---> Server
30+
```
31+
32+
3. **Server Response**:
33+
- If successful:
34+
```
35+
Client <--- RequestExtensions.Success [0x0002] ---- Server
36+
```
37+
- If an error occurs:
38+
```
39+
Client <--- RequestExtensions.Error [0x0002] ---- Server
40+
```
41+
42+
The client MUST include the `user_identity` field in the `SubmitSharesExtended` message only if the extension has been successfully activated.
43+
44+
### 1.2 Bandwidth Consideration
45+
46+
Including the `user_identity` field in each share submission increases message size, depending on the length of the identifier (up to 32 bytes).
47+
48+
For example:
49+
- **Without `user_identity`**: Share message size ~70 bytes.
50+
- **With maximum `user_identity` (32 bytes)**: Share message size ~102 bytes.
51+
52+
In a scenario with 10 shares per minute per channel:
53+
- **Maximum increase**: 32 bytes × 10 = 320 bytes/min, or 19.2 KB/hour.
54+
- **Average increase (20 bytes)**: 200 bytes/min, or 12 KB/hour.
55+
56+
---
57+
58+
## 2. Modified Messages
59+
60+
### `SubmitSharesExtended` (Client -> Server)
61+
62+
The `SubmitSharesExtended` message is updated as follows:
63+
64+
| Field Name | Data Type | Description |
65+
|-----------------|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
66+
| channel_id | U32 | Channel identification. |
67+
| sequence_number | U32 | Unique sequential identifier of the submit within the channel. |
68+
| job_id | U32 | Identifier of the job as provided by NewMiningJob or NewExtendedMiningJob message. |
69+
| nonce | U32 | Nonce leading to the hash being submitted. |
70+
| ntime | U32 | The nTime field in the block header. This MUST be greater than or equal to the header_timestamp field in the latest SetNewPrevHash message and lower than or equal to that value plus the number of seconds since the receipt of that message. |
71+
| version | U32 | Full nVersion field. |
72+
| extranonce | B0_32 | Extranonce bytes which need to be added to coinbase to form a fully valid submission (full coinbase = coinbase_tx_prefix + extranonce_prefix + extranonce + coinbase_tx_suffix). The size of the provided extranonce MUST be equal to the negotiated extranonce size from channel opening. |
73+
| user_identity | STR0_32 | A unique string identifying the worker. Maximum of 32 bytes. |
74+
75+
---
76+
77+
## 3. Implementation Notes
78+
79+
### 3.1 Job Difficulty Management
80+
81+
As the number of workers in a single extended channel increases, the time required to receive shares from all individual machines also increases. If a server wants to offer this monitoring, it should manage job difficulty accordingly to ensure timely processing of shares.
82+
83+
### 3.2 Privacy Considerations
84+
85+
Mining farms should be aware that sharing per-worker data with pools could reveal operational insights. This could potentially compromise the privacy of the mining farm's operations.
86+
87+
---

0 commit comments

Comments
 (0)