Replace JN with JD text and StratumV2 with Stratum v2

src/docs/index.md

@@ -2,34 +2,34 @@
 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
 
 The actual mining machines which compute hashes. Miners may refer to a wide variety of hashrate producers; from large-scale corporate mining farms to wildcat mobile mining operations capturing flare gas on a temporory shale drilling site. Miners are most usefully referred to at the scale they communicate upstream to a pool: a 10PH mining farm colocated with a hydro dam that communicates as a single unit to the pool and splits its work internally may be thought of as a single 'miner', separate from the 'miner' operating a single S19 in his garage down the street. Miners "point" their hashrate at a Pool, defined below.
 
 ### 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 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 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 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 (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
 
-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,16 +44,16 @@ 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
 
 Used to get information about the next block out of Bitcoin Core. This protocol was designed as a much more efficient and easy-to-implement API to replace getblocktemplate (BIPs 22 and 23). More specifically, the Template Distribution Protocol is used to communicate with a part of Bitcoin Core called “bitcoind” which implements the Bitcoin protocol for Remote Procedure Call (RPC) use. In other words, bitcoind allows the Bitcoin protocol to be integrated with other software.
 
 ### 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.

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
 
@@ -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
 

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/
 ```

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