You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 02-Design-Goals.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ As there are numerous changes from the original Stratum v1 to v2, it may be help
28
28
29
29
- Dramatically reduce network traffic as well as client-side and server-side computational intensity, while still being able to send and receive hashing results rapidly for precise hash rate measurement (and therefore more precise mining reward distribution).
30
30
31
-
- Allow miners to (optionally) choose the transaction set they mine through work negotiation on some independent communication channel.
31
+
- Allow miners to (optionally) choose the transaction set they mine through work declaration on some independent communication channel.
32
32
At the same time, allow miners to choose how they utilize the available bits in the block header `nVersion` field, including both those bits which are used for mining (e.g. version-rolling AsicBoost) by [BIP320](https://github.com/bitcoin/bips/blob/master/bip-0320.mediawiki), and those bits used for [BIP8](https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki)/[BIP9](https://github.com/bitcoin/bips/tree/master/bip-0009) signaling.
33
33
This mechanism must not interfere with the efficiency or security of the main mining protocol.
34
34
- Use a separate communication channel for transaction selection so that it does not have a performance impact on the main mining/share communication, as well as can be run in three modes - disabled (i.e.pool does not yet support client work selection, to provide an easier transition from Stratum v1), client-push (to maximally utilize the client’s potential block-receive-latency differences from the pool), and client-negotiated (for pools worried about the potential of clients generating invalid block templates).
Copy file name to clipboardExpand all lines: 03-Protocol-Overview.md
+17-17
Original file line number
Diff line number
Diff line change
@@ -9,50 +9,50 @@ There are technically four distinct (sub)protocols needed in order to fully use
9
9
This protocol needs to be implemented in all scenarios.
10
10
For cases in which a miner or pool does not support transaction selection, this is the only protocol used.
11
11
12
-
2.**Job Negotiation Protocol**
13
-
Used by a miner (a whole mining farm) to negotiate a block template with a pool.
14
-
Results of this negotiation can be re-used for all mining connections to the pool to reduce computational intensity.
15
-
In other words, a single negotiation can be used by an entire mining farm or even multiple farms with hundreds of thousands of devices, making it far more efficient.
12
+
2.**Job Declaration Protocol**
13
+
Used by a miner (a whole mining farm) to declare a block template with a pool.
14
+
Results of this declaration can be re-used for all mining connections to the pool to reduce computational intensity.
15
+
In other words, a single declaration can be used by an entire mining farm or even multiple farms with hundreds of thousands of devices, making it far more efficient.
16
16
This is separate to allow pools to terminate such connections on separate infrastructure from mining protocol connections (i.e. share submissions).
17
-
Further, such connections have very different concerns from share submissions - work negotiation likely requires, at a minimum, some spot-checking of work validity, as well as potentially substantial rate-limiting (without the inherent rate-limiting of share difficulty).
17
+
Further, such connections have very different concerns from share submissions - work declaration likely requires, at a minimum, some spot-checking of work validity, as well as potentially substantial rate-limiting (without the inherent rate-limiting of share difficulty).
18
18
19
19
3.**Template Distribution Protocol**
20
20
A similarly-framed protocol for getting information about the next block out of Bitcoin Core.
21
21
Designed to replace `getblocktemplate` with something much more efficient and easy to implement for those implementing other parts of Stratum v2.
22
22
23
23
4.**Job Distribution Protocol**
24
-
Simple protocol for passing newly-negotiated work to interested nodes - either proxies or miners directly.
25
-
This protocol is left to be specified in a future document, as it is often unnecessary due to the Job Negotiation role being a part of a larger Mining Protocol Proxy.
24
+
Simple protocol for passing newly-declared work to interested nodes - either proxies or miners directly.
25
+
This protocol is left to be specified in a future document, as it is often unnecessary due to the Job Declaration role being a part of a larger Mining Protocol Proxy.
26
26
27
27
Meanwhile, there are five possible roles (types of software/hardware) for communicating with these protocols.
28
28
29
29
1.**Mining Device**
30
30
The actual device computing the hashes. This can be further divided into header-only mining devices and standard mining devices, though most devices will likely support both modes.
31
31
32
32
2.**Pool Service**
33
-
Produces jobs (for those not negotiating jobs via the Job Negotiation Protocol), validates shares, and ensures blocks found by clients are propagated through the network (though clients which have full block templates MUST also propagate blocks into the Bitcoin P2P network).
33
+
Produces jobs (for those not declarating jobs via the Job Declaration Protocol), validates shares, and ensures blocks found by clients are propagated through the network (though clients which have full block templates MUST also propagate blocks into the Bitcoin P2P network).
34
34
35
35
3.**Mining Proxy (optional)**
36
36
Sits in between Mining Device(s) and Pool Service, aggregating connections for efficiency.
37
-
May optionally provide additional monitoring, receive work from a Job Negotiator and use custom work with a pool, or provide other services for a farm.
37
+
May optionally provide additional monitoring, receive work from a Job Declarator and use custom work with a pool, or provide other services for a farm.
38
38
39
-
4.**Job Negotiator (optional)**
40
-
Receives custom block templates from a Template Provider and negotiates use of the template with the pool using the Job Negotiation Protocol.
39
+
4.**Job Declarator (optional)**
40
+
Receives custom block templates from a Template Provider and declares use of the template with the pool using the Job Declaration Protocol.
41
41
Further distributes the jobs to Mining Proxy (or Proxies) using the Job Distribution Protocol. This role will often be a built-in part of a Mining Proxy.
42
42
43
43
5.**Template Provider**
44
-
Generates custom block templates to be passed to the Job Negotiator for eventual mining.
44
+
Generates custom block templates to be passed to the Job Declarator for eventual mining.
45
45
This is usually just a Bitcoin Core full node (or possibly some other node implementation).
46
46
47
47
The Mining Protocol is used for communication between a Mining Device and Pool Service, Mining Device and Mining Proxy, Mining Proxy and Mining Proxy, or Mining Proxy and Pool Service.
48
48
49
-
The Job Negotiation Protocol is used for communication between a Job Negotiator and Pool Service.
49
+
The Job Declaration Protocol is used for communication between a Job Declarator and Pool Service.
50
50
51
-
The Template Distribution Protocol is used for communication either between a Job Negotiator and a Template Provider or between a Pool Service and Template Provider.
51
+
The Template Distribution Protocol is used for communication either between a Job Declarator and a Template Provider or between a Pool Service and Template Provider.
52
52
53
-
The Job Distribution Protocol is used for communication between a Job Negotiator and a Mining Proxy.
53
+
The Job Distribution Protocol is used for communication between a Job Declarator and a Mining Proxy.
54
54
55
-
One type of software/hardware can fulfill more than one role (e.g. a Mining Proxy is often both a Mining Proxy and a Job Negotiator and may occasionally further contain a Template Provider in the form of a full node on the same device).
55
+
One type of software/hardware can fulfill more than one role (e.g. a Mining Proxy is often both a Mining Proxy and a Job Declarator and may occasionally further contain a Template Provider in the form of a full node on the same device).
56
56
57
57
Each sub-protocol is based on the same technical principles and requires a connection oriented transport layer, such as TCP.
58
58
In specific use cases, it may make sense to operate the protocol over a connectionless transport with FEC or local broadcast with retransmission.
@@ -98,7 +98,7 @@ The message framing is outlined below:
| extension_type | U16 | Unique identifier of the extension describing this protocol message. <br>Most significant bit (i.e.bit 15, 0-indexed, aka channel_msg) indicates a message which is specific to a channel, whereas if the most significant bit is unset, the message is to be interpreted by the immediate receiving device. <br>Note that the channel_msg bit is ignored in the extension lookup, i.e.an extension_type of 0x8ABC is for the same "extension" as 0x0ABC. <br>If the channel_msg bit is set, the first four bytes of the payload field is a U32 representing the channel_id this message is destined for (these bytes are repeated in the message framing descriptions below). <br>Note that for the Job Negotiation and Template Distribution Protocols the channel_msg bit is always unset. |
101
+
| extension_type | U16 | Unique identifier of the extension describing this protocol message. <br>Most significant bit (i.e.bit 15, 0-indexed, aka channel_msg) indicates a message which is specific to a channel, whereas if the most significant bit is unset, the message is to be interpreted by the immediate receiving device. <br>Note that the channel_msg bit is ignored in the extension lookup, i.e.an extension_type of 0x8ABC is for the same "extension" as 0x0ABC. <br>If the channel_msg bit is set, the first four bytes of the payload field is a U32 representing the channel_id this message is destined for (these bytes are repeated in the message framing descriptions below). <br>Note that for the Job Declaration and Template Distribution Protocols the channel_msg bit is always unset. |
102
102
| msg_type | U8 | Unique identifier of the extension describing this protocol message |
103
103
| msg_length | U24 | Length of the protocol message, not including this header |
104
104
| payload | BYTES | Message-specific payload of length msg_length. If the MSB in extension_type (the channel_msg bit) is set the first four bytes are defined as a U32 "channel_id", though this definition is repeated in the message definitions below and these 4 bytes are included in msg_length. |
Copy file name to clipboardExpand all lines: 04-Protocol-Security.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ At the same time, this specification proposes optional use of a particular hands
9
9
The client and server establish secure communication using Diffie-Hellman (DH) key agreement, as described in greater detail in the Authenticated Key Agreement Handshake section below.
10
10
11
11
Using the handshake protocol to establish secured communication is **optional** on the local network (e.g. local mining devices talking to a local mining proxy).
12
-
However, it is **mandatory** for remote access to the upstream nodes, whether they be pool mining services, job negotiating services or template distributors.
12
+
However, it is **mandatory** for remote access to the upstream nodes, whether they be pool mining services, job declarating services or template distributors.
13
13
14
14
## 4.1 Motivation for Authenticated Encryption with Associated Data
`SetupConnection.flags` MUST contain `REQUIRES_WORK_SELECTION` flag (work selection feature successfully negotiated).
362
+
`SetupConnection.flags` MUST contain `REQUIRES_WORK_SELECTION` flag (work selection feature successfully declared).
363
363
364
-
The downstream node has a custom job negotiated by a trusted external Job Negotiator.
365
-
The `mining_job_token` provides the information for the pool to authorize the custom job that has been or will be negotiated between the Job Negotiator and Pool.
364
+
The downstream node has a custom job declared by a trusted external Job Declarator.
365
+
The `mining_job_token` provides the information for the pool to authorize the custom job that has been or will be declared between the Job Declarator and Pool.
| mining_job_token | B0_255 | Token provided by the pool which uniquely identifies the job that the Job Negotiator has negotiated with the pool. See the Job Negotiation Protocol for more details. |
371
+
| mining_job_token | B0_255 | Token provided by the pool which uniquely identifies the job that the Job Declarator has declared with the pool. See the Job Declaration Protocol for more details. |
372
372
| version | U32 | Valid version field that reflects the current network consensus. The general purpose bits (as specified in BIP320) can be freely manipulated by the downstream node. |
373
373
| prev_hash | U256 | Previous block’s hash, found in the block header field |
374
374
| min_ntime | U32 | Smallest nTime value available for hashing |
0 commit comments