From 884771628e3e78a536f0fe73a0cb080cbf8d55c5 Mon Sep 17 00:00:00 2001 From: Pavlenex <36959754+pavlenex@users.noreply.github.com> Date: Fri, 29 Sep 2023 11:25:16 +0200 Subject: [PATCH 1/4] replace jn with jd text --- src/docs/index.md | 18 +++++++++--------- src/features.md | 4 ++-- src/getting-started.md | 6 +++--- src/index.md | 4 ++-- 4 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/docs/index.md b/src/docs/index.md index 402fe14..8c6dd7a 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -20,16 +20,16 @@ Pools operate as communication nodes to coordinate hashrate and distribute minin ### Proxies -Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job negotiation optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A StratumV2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. +Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job declaration optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A StratumV2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. -### Job Negotiators +### job declarators -Job Negotiators (JNs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They negotiate template use with the pool per the Job Negotiation Protocol. +job declarators (JNs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They negotiate template use with the pool per the Job declaration Protocol. They can further distribute jobs to a Mining Proxy (or Proxies) via the Job Distribution Protocol. ### Template Providers -Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the Job Negotiator via the Job Negotiation Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. +Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. ## Sub-Protocols @@ -44,11 +44,11 @@ The protocol defines three types of communication channels: - Group channels are simply collections of standard channels that are opened within a particular connection so that they are addressable through a common communication channel. -### Job Negotiation Protocol +### Job declaration Protocol -A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's Job Negotiator. The Pool can reuse negotiation outcomes across all end-miner connections to reduce computational intensity. A single negotiation can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. -Separating job negotiation as a sub-protocol lets pools terminate negotiation connections independently of mining protocol connections (i.e. share submissions). -Work negotiation likely requires, at minimum, validity spot-checks and (potentially) rate-limiting. +A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's job declarator. The Pool can reuse declaration outcomes across all end-miner connections to reduce computational intensity. A single declaration can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. +Separating job declaration as a sub-protocol lets pools terminate declaration connections independently of mining protocol connections (i.e. share submissions). +Work declaration likely requires, at minimum, validity spot-checks and (potentially) rate-limiting. ### Template Distribution Protocol @@ -56,4 +56,4 @@ Used to get information about the next block out of Bitcoin Core. This protocol ### Job Distribution Protocol -Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Negotiation protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job Negotiation role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets. +Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job declaration protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets. diff --git a/src/features.md b/src/features.md index 89a5885..43b854f 100644 --- a/src/features.md +++ b/src/features.md @@ -98,11 +98,11 @@ Miners can choose their own work and mine their chosen transaction set in Sv2, f Job Selection by end-miners is an optional component of Stratum V2, separate from the main mining protocol. In fact, this is actually done by three sub-protocols: -1. Job Negotiation Protocol +1. Job declaration Protocol 2. Job Distribution Protocol 3. Template Distribution Protocol. -Job selection is a negotiation process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a negotiated template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions. +Job selection is a declaration process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a negotiated template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions. #### Motivation & Impact diff --git a/src/getting-started.md b/src/getting-started.md index d33cb6a..7117dce 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -259,9 +259,9 @@ Eventually, the Translation Proxy log output will show sucessful share, which me ``` -## Config D: SV1 firmware > Translation Proxy JN (Job Negotiator) > SV2 Pool +## Config D: SV1 firmware > Translation Proxy JN (job declarator) > SV2 Pool -This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **Job Negotiator (JN)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JN**. +This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **job declarator (JN)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JN**. In the following guide a Template Provider is installed locally on the same machine, to provide block templates to the JN. ![Config2](/assets/config-d.svg) @@ -392,7 +392,7 @@ If the pool properly starts you should see the following log lines: ### 3. Start **Translator (tProxy) JN** Once the SV2 pool is running, let's run the tProxy that will facilitate communication between the pool and a SV1 miner. -Differently from the Config C, in this case the **tProxy** will be acting as a **Job Negotiator (JN)**, so it will select transactions locally and send them to the **Pool-side JN** +Differently from the Config C, in this case the **tProxy** will be acting as a **job declarator (JN)**, so it will select transactions locally and send them to the **Pool-side JN** ``` cd stratum/roles/translator/ ``` diff --git a/src/index.md b/src/index.md index 88e5501..5051915 100644 --- a/src/index.md +++ b/src/index.md @@ -49,8 +49,8 @@ roadmapTagline: This is where the Stratum V2 protocol’s progress currently sta roadmapSteps: - __MVP1__ will allow users to run SV2 where a miner runs existing SV1 firmware with a proxy that translates messages into SV2. In this configuration, the pool selects transactions. - A pull request that implements a **block template provider** will be submitted to the Bitcoin Core repository for review which will make MVP1 complete. - - Implement the **job negotiator**, which a miner or miners can use to declare a block template to a pool. - - Once a translator, template provider, and job negotiator are running, we will launch an MVP2. In this configuration, a miner handles mempool transaction selection, and the pool accepts it. + - Implement the **job declarator**, which a miner or miners can use to declare a block template to a pool. + - Once a translator, template provider, and job declarator are running, we will launch an MVP2. In this configuration, a miner handles mempool transaction selection, and the pool accepts it. - Apply early adopter feedback and tailor configurations that will move MVP1 and MVP2 from beta to production-ready. # Specification authors section specificationAuthorsTitle: Stratum V2 specification authors From 5d65b48ff050ebf74db551ab840c849c6bf70a95 Mon Sep 17 00:00:00 2001 From: Pavlenex <36959754+pavlenex@users.noreply.github.com> Date: Fri, 29 Sep 2023 11:31:54 +0200 Subject: [PATCH 2/4] stratum v2 consistency in wording, and uppercase JD --- src/docs/index.md | 18 +++++++++--------- src/features.md | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/docs/index.md b/src/docs/index.md index 8c6dd7a..2c33668 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -2,13 +2,13 @@ pageHeading: Roles and Protocols --- -# StratumV2 Overview +# Stratum v2 Overview -The StratumV2 Protocol Suite consists of 4 Protocols (the main Mining Protocol and 3 sub-protocols) which specify the communication standards among 5 Roles for Bitcoin Mining entities. This section defines the roles and provides a summary of each sub-protocol's implementation. For technical specifications, please refer to the full documentation on [Github](https://www.github.com/stratum-mining/sv2-spec). +The Stratum v2 Protocol Suite consists of 4 Protocols (the main Mining Protocol and 3 sub-protocols) which specify the communication standards among 5 Roles for Bitcoin Mining entities. This section defines the roles and provides a summary of each sub-protocol's implementation. For technical specifications, please refer to the full documentation on [Github](https://www.github.com/stratum-mining/sv2-spec). ## Roles -We define 5 Roles for entities in the StratumV2 Protocol Suite: +We define 5 Roles for entities in the Stratum v2 Protocol Suite: ### Mining Devices or Miners @@ -16,15 +16,15 @@ The actual mining machines which compute hashes. Miners may refer to a wide vari ### Pools (Hashrate Consumers) -Pools operate as communication nodes to coordinate hashrate and distribute mining rewards. They create jobs for end-mining devices, validate blocks and shares, and propagate found blocks to the Bitcoin Network. Pools do not custody or control hashrate. End-mining devices compatible with the Stratum protocol can switch between pools in minutes. Pools therefore compete for hashrate based on latency, ease-of-use, payout reliability, and associated networking services, all of which StratumV2 can significantly improve. +Pools operate as communication nodes to coordinate hashrate and distribute mining rewards. They create jobs for end-mining devices, validate blocks and shares, and propagate found blocks to the Bitcoin Network. Pools do not custody or control hashrate. End-mining devices compatible with the Stratum protocol can switch between pools in minutes. Pools therefore compete for hashrate based on latency, ease-of-use, payout reliability, and associated networking services, all of which Stratum v2 can significantly improve. ### Proxies -Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job declaration optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A StratumV2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. +Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job declaration optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A Stratum v2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. -### job declarators +### Job Declarators -job declarators (JNs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They negotiate template use with the pool per the Job declaration Protocol. +Job Declarators (JDs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They declare the template to the pool per the Job Declaration Protocol. They can further distribute jobs to a Mining Proxy (or Proxies) via the Job Distribution Protocol. ### Template Providers @@ -44,9 +44,9 @@ The protocol defines three types of communication channels: - Group channels are simply collections of standard channels that are opened within a particular connection so that they are addressable through a common communication channel. -### Job declaration Protocol +### Job Declaration Protocol -A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's job declarator. The Pool can reuse declaration outcomes across all end-miner connections to reduce computational intensity. A single declaration can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. +A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's Job Declarator. The Pool can reuse declaration outcomes across all end-miner connections to reduce computational intensity. A single declaration can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. Separating job declaration as a sub-protocol lets pools terminate declaration connections independently of mining protocol connections (i.e. share submissions). Work declaration likely requires, at minimum, validity spot-checks and (potentially) rate-limiting. diff --git a/src/features.md b/src/features.md index 43b854f..7df3a6f 100644 --- a/src/features.md +++ b/src/features.md @@ -4,7 +4,7 @@ pageHeading: SV2 in Detail # Features -StratumV2 offers superior security, flexibility, and performance. This section details the motivations and technical descriptions behind V2's protocol design decisions. +Stratum v2 offers superior security, flexibility, and performance. This section details the motivations and technical descriptions behind V2's protocol design decisions. ## Bandwidth Consumption From 82a443ac23604eb511c76f8b8a20b2d14494bd04 Mon Sep 17 00:00:00 2001 From: Pavlenex <36959754+pavlenex@users.noreply.github.com> Date: Mon, 2 Oct 2023 11:37:29 +0200 Subject: [PATCH 3/4] add suggestions from review Co-Authored-By: Gabriele Vernetti <62447440+GitGab19@users.noreply.github.com> --- src/docs/index.md | 4 ++-- src/features.md | 4 ++-- src/getting-started.md | 10 +++++----- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/docs/index.md b/src/docs/index.md index 2c33668..5e07b02 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -29,7 +29,7 @@ They can further distribute jobs to a Mining Proxy (or Proxies) via the Job Dist ### Template Providers -Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. +Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job Declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. ## Sub-Protocols @@ -56,4 +56,4 @@ Used to get information about the next block out of Bitcoin Core. This protocol ### Job Distribution Protocol -Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job declaration protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets. +Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Declaration Protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets. diff --git a/src/features.md b/src/features.md index 7df3a6f..bdd7cda 100644 --- a/src/features.md +++ b/src/features.md @@ -98,11 +98,11 @@ Miners can choose their own work and mine their chosen transaction set in Sv2, f Job Selection by end-miners is an optional component of Stratum V2, separate from the main mining protocol. In fact, this is actually done by three sub-protocols: -1. Job declaration Protocol +1. Job Declaration Protocol 2. Job Distribution Protocol 3. Template Distribution Protocol. -Job selection is a declaration process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a negotiated template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions. +Job selection is a declaration process between miner and pool. The miner proposes a block template; the pool accepts or rejects it. Once a declared template is accepted, the template can be multicast to other mining devices and farms. Implementing Job Selection Protocols separately allows pools to terminate connections on seperate infrastructure from the main mining protocol, preventing impact on the efficiency of share submissions. #### Motivation & Impact diff --git a/src/getting-started.md b/src/getting-started.md index 7117dce..36b7e9f 100644 --- a/src/getting-started.md +++ b/src/getting-started.md @@ -259,10 +259,10 @@ Eventually, the Translation Proxy log output will show sucessful share, which me ``` -## Config D: SV1 firmware > Translation Proxy JN (job declarator) > SV2 Pool +## Config D: SV1 firmware > Translation Proxy JD (Job Declarator) > SV2 Pool -This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **job declarator (JN)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JN**. -In the following guide a Template Provider is installed locally on the same machine, to provide block templates to the JN. +This configuration allows mining devices running SV1 firmware to connect to an SV2 Pool through a Translation Proxy (tProxy). In this case the tProxy is designed also to implement the **Job Declarator (JD)** sub-protocol: allowing miners to select transactions locally and send them to the **Pool-side JDS (Job Declarator Server)**. +In the following guide a Template Provider is installed locally on the same machine, to provide block templates to the JD. ![Config2](/assets/config-d.svg) @@ -389,10 +389,10 @@ If the pool properly starts you should see the following log lines: > cargo run -p pool_sv2 -- -c [your-custom-config.toml] > ``` -### 3. Start **Translator (tProxy) JN** +### 3. Start **Translator (tProxy) JD** Once the SV2 pool is running, let's run the tProxy that will facilitate communication between the pool and a SV1 miner. -Differently from the Config C, in this case the **tProxy** will be acting as a **job declarator (JN)**, so it will select transactions locally and send them to the **Pool-side JN** +Differently from the Config C, in this case the **tProxy** will be acting as a **Job Declarator (JD)**, so it will select transactions locally and send them to the **Pool-side JDS** ``` cd stratum/roles/translator/ ``` From 0615bc959a271bb243e7daacdabfbb9c353d4a02 Mon Sep 17 00:00:00 2001 From: Pavlenex <36959754+pavlenex@users.noreply.github.com> Date: Fri, 6 Oct 2023 15:26:53 +0200 Subject: [PATCH 4/4] revert to avoid conflicts with #187 --- src/docs/index.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/src/docs/index.md b/src/docs/index.md index 5e07b02..402fe14 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -2,13 +2,13 @@ pageHeading: Roles and Protocols --- -# Stratum v2 Overview +# StratumV2 Overview -The Stratum v2 Protocol Suite consists of 4 Protocols (the main Mining Protocol and 3 sub-protocols) which specify the communication standards among 5 Roles for Bitcoin Mining entities. This section defines the roles and provides a summary of each sub-protocol's implementation. For technical specifications, please refer to the full documentation on [Github](https://www.github.com/stratum-mining/sv2-spec). +The StratumV2 Protocol Suite consists of 4 Protocols (the main Mining Protocol and 3 sub-protocols) which specify the communication standards among 5 Roles for Bitcoin Mining entities. This section defines the roles and provides a summary of each sub-protocol's implementation. For technical specifications, please refer to the full documentation on [Github](https://www.github.com/stratum-mining/sv2-spec). ## Roles -We define 5 Roles for entities in the Stratum v2 Protocol Suite: +We define 5 Roles for entities in the StratumV2 Protocol Suite: ### Mining Devices or Miners @@ -16,20 +16,20 @@ The actual mining machines which compute hashes. Miners may refer to a wide vari ### Pools (Hashrate Consumers) -Pools operate as communication nodes to coordinate hashrate and distribute mining rewards. They create jobs for end-mining devices, validate blocks and shares, and propagate found blocks to the Bitcoin Network. Pools do not custody or control hashrate. End-mining devices compatible with the Stratum protocol can switch between pools in minutes. Pools therefore compete for hashrate based on latency, ease-of-use, payout reliability, and associated networking services, all of which Stratum v2 can significantly improve. +Pools operate as communication nodes to coordinate hashrate and distribute mining rewards. They create jobs for end-mining devices, validate blocks and shares, and propagate found blocks to the Bitcoin Network. Pools do not custody or control hashrate. End-mining devices compatible with the Stratum protocol can switch between pools in minutes. Pools therefore compete for hashrate based on latency, ease-of-use, payout reliability, and associated networking services, all of which StratumV2 can significantly improve. ### Proxies -Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job declaration optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A Stratum v2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. +Proxies are intermediaries between Miners and Pools that aggregate connections and translate mining communications from v1->v2 or v2->v1. Proxies may optionally provide additional functionality including monitoring services or job negotiation optimizations. Both Miners and Pools can run Proxies, and will do so for various reasons depending on the use-case. e.g. A StratumV2 pool might run a proxy as its initial connection service to accept both V1 and V2 connections, establishing direct standard channels with the V2 miners and using the proxy to translate messages with the v1 miners. -### Job Declarators +### Job Negotiators -Job Declarators (JDs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They declare the template to the pool per the Job Declaration Protocol. +Job Negotiators (JNs) are Pool-side Proxies that receive and validate custom block templates from Template Providers. They negotiate template use with the pool per the Job Negotiation Protocol. They can further distribute jobs to a Mining Proxy (or Proxies) via the Job Distribution Protocol. ### Template Providers -Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the job declarator via the Job Declaration Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. +Template Providers (TPs) are Miner-side Proxies that create custom block templates and negotiate their use with the Job Negotiator via the Job Negotiation Protocol. Template Providers are usually a Bitcoin Core full node, but can also work with a different node implementation. ## Sub-Protocols @@ -44,11 +44,11 @@ The protocol defines three types of communication channels: - Group channels are simply collections of standard channels that are opened within a particular connection so that they are addressable through a common communication channel. -### Job Declaration Protocol +### Job Negotiation Protocol -A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's Job Declarator. The Pool can reuse declaration outcomes across all end-miner connections to reduce computational intensity. A single declaration can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. -Separating job declaration as a sub-protocol lets pools terminate declaration connections independently of mining protocol connections (i.e. share submissions). -Work declaration likely requires, at minimum, validity spot-checks and (potentially) rate-limiting. +A Miner's Template Provider negotiates a block template (which includes the transaction set) with a Pool's Job Negotiator. The Pool can reuse negotiation outcomes across all end-miner connections to reduce computational intensity. A single negotiation can multicast to multiple farms with hundreds of thousands of devices. This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms. +Separating job negotiation as a sub-protocol lets pools terminate negotiation connections independently of mining protocol connections (i.e. share submissions). +Work negotiation likely requires, at minimum, validity spot-checks and (potentially) rate-limiting. ### Template Distribution Protocol @@ -56,4 +56,4 @@ Used to get information about the next block out of Bitcoin Core. This protocol ### Job Distribution Protocol -Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Declaration Protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job declaration role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets. +Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Negotiation protocol. In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job Negotiation role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets.