Skip to content

Commit

Permalink
Merge pull request #182 from pavlenex/job-declarator
Browse files Browse the repository at this point in the history
Replace `JN` with `JD` text and `StratumV2` with `Stratum v2`
  • Loading branch information
pavlenex authored Oct 6, 2023
2 parents beba23b + 0615bc9 commit e220bfb
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 10 deletions.
6 changes: 3 additions & 3 deletions src/features.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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 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

Expand Down
10 changes: 5 additions & 5 deletions src/getting-started.md
Original file line number Diff line number Diff line change
Expand Up @@ -259,10 +259,10 @@ 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 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 Negotiator (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)

Expand Down Expand Up @@ -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 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 (JD)**, so it will select transactions locally and send them to the **Pool-side JDS**
```
cd stratum/roles/translator/
```
Expand Down
4 changes: 2 additions & 2 deletions src/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down

0 comments on commit e220bfb

Please sign in to comment.