Improve cpu miner

roles/jd-client/README.md

@@ -1,38 +1,34 @@
 # JD Client
-The JD Client is a Sv2 proxy that support one extended channel upstream and one extended channel
-dowstream, and do job declaration. On start it will:
+
 * connect to the jd-server
 * connect to the template-provider
-* listen for and `OpenExtendedChannel` from downstream
+The JD Client receives custom block templates from a Template Provider and declares use of the template with the pool using the Job Declaration Protocol. Further distributes the jobs to Mining Proxy (or Proxies) using the Job Distribution Protocol. ```
 * transparently relay the `OpenExtendedChannel` to upstream 
-After the setup phase it will start to negotiate jobs with upstream and send the negotiated job
-downstream, so that everything that is dowstream do not need to know that job is negotiated.
 
 ## Setup
+
 ### Configuration File
-The `proxy-config-example.toml` is a configuration example.
 
 The configuration file contains the following information:
 
-1. The Upstream connection information which includes the SV2 Pool authority public key 
-   (`upstream_authority_pubkey`) and the SV2 Pool connection address (`upstream_address`) and port
-   (`upstream_port`).
-2. The maximum and minimum SV2 versions (`max_supported_version` and `min_supported_version`)
-3. The Job Declarator information which includes the Pool JD connection address (`jd_address`) and the Template Provider connection address to which to connect (`tp_address`).
-4. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
-```
+1. The downstream socket information, which includes the listening IP address (`downstream_address`) and port (`downstream_port`).
+2. The maximum and minimum SRI versions (`max_supported_version` and `min_supported_version`) with size as (`min_extranonce2_size`)
+3. The authentication keys for the downstream connection (`authority_public_key`, `authority_secret_key`)
+4. A `retry` parameter which tells JDC the number of times to reinitialize itself after a failure.
+6. The Template Provider address (`tp_address`).
+7. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
+
 # 2024-02-13T14:59:24Z Template Provider authority key: EguTM8URcZDQVeEBsM4B5vg9weqEUnufA8pm85fG4bZd
-```
 
 ### Run
-1. Copy the `jdc-config-example.toml` into `conf/` directory.
-2. Edit it with custom desired configuration and rename it `jdc-config.toml`
-3. Point the SV1 Downstream Mining Device(s) to the Translator Proxy IP address and port.
-4. Run the Translator Proxy:
-
-   ```
-   cd roles/translator
-   ```
-   ```
-   cargo run -p translator_sv2 -- -c conf/jdc-config.toml
-   ```
+
+Run the Job Declarator Client (JDC):
+There are two files when you cd into roles/jd-client/config-examples/
+
+1. `jdc-config-hosted-example.toml` connects to the community-hosted roles.
+2. `jdc-config-local-example.toml` connects to self-hosted Job Declarator Client (JDC) and Translator Proxy
+
+``` bash
+cd roles/jd-client/config-examples/
+cargo run -- -c jdc-config-hosted-example.toml
+```

roles/pool/README.md

@@ -1,4 +1,6 @@
+
 # SRI Pool
+
 SRI Pool is designed to communicate with Downstream role (most typically a Translator Proxy or a Mining Proxy) running SV2 protocol to exploit features introduced by its sub-protocols.
 
 The most typical high level configuration is:
@@ -18,47 +20,35 @@ The most typical high level configuration is:
 ```
 
 ## Setup
+
 ### Configuration File
-The `pool-config-example.toml` is a configuration example which can be copy/paste into `/conf` directory by the party that is running the SV2 Pool (most
-typically the pool service provider) to address the most preferred customization.
+
+`pool-config-hosted-tp-example.toml` and `pool-config-local-tp-example.toml` are examples of configuration files.
 
 The configuration file contains the following information:
 
-1. The SRI Pool information which includes the SRI Pool authority public key 
-   (`authority_pubkey`), the SRI Pool authority secret key (`authority_secret_key`), along with its certificate validity (`cert_validity_sec`). In addition to this, it contains the address which it will use to listen to new connection from downstream roles (`listen_address`) and the list of uncompressed pubkeys for coinbase payout (`coinbase_outputs`).
-2. The SRI Pool Job Negatiator information which includes the Template Provider address (`tp_address`) and the address it uses to listen new request from the downstream JDs (`jd_address`).
-3. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
+1. The SRI Pool information which includes the SRI Pool authority public key
+   (`authority_public_key`), the SRI Pool authority secret key (`authority_secret_key`).
+2. The address which it will use to listen to new connection from downstream roles (`listen_address`)
+3. The list of uncompressed pubkeys for coinbase payout (`coinbase_outputs`)
+4. A string that serves as signature on the coinbase tx (`pool_signature`).
+5. The Template Provider address (`tp_address`).
+6. Optionally, you may want to verify that your TP connection is authentic. You may get `tp_authority_public_key` from the logs of your TP, for example:
+
 ```
 # 2024-02-13T14:59:24Z Template Provider authority key: EguTM8URcZDQVeEBsM4B5vg9weqEUnufA8pm85fG4bZd
 ```
 
 ### Run
-1. Copy the `pool-config-example.toml` into `conf/` directory.
-2. Edit it with custom desired configuration and rename it `pool-config.toml`
-   > <ins>**Warning**</ins><br>
-   > If you want to mine spendable bitcoin on regtest, you can do it with bitcoin-cli:
-   > 1. Get a legacy Bitcoin address:
-   >   ```
-   >   bitcoin-cli -regtest -rpcwallet="<PUT YOUR WALLET NAME HERE>" getnewaddress "test" "legacy"
-   >   ```
-   > 2. Retrieve its corresponding public key:
-   >   ```
-   >   bitcoin-cli -regtest getaddressinfo <PUT THE ADDRESS GENERATED HERE>
-   >   ```
-   > 3. Copy the pubkey showed in the output
-   > 4. Paste it in the `coinbase_outputs` of `pool-config.toml`, after deleting the one which is already present
-   > 5. Mine a block
-   > 6. Generate 100 blocks 
-   >   ```
-   >   bitcoin-cli -regtest generatetoaddress 100 bcrt1qc5xss0cma0zldxfzzdpjxsayut7yy86e2lr6km
-   >   ```
-   > Now the mined bitcoin are spendable!
-
-3. Run the Pool:
-
-   ```
-   cd roles/v2/pool
-   ```
-   ```
-   cargo run -p pool_sv2 -- -c conf/pool-config.toml
-   ```
+
+There are two files found in `roles/pool/config-examples`
+
+1. `pool-config-hosted-tp-example.toml` runs on our community hosted server.
+2. `pool-config-example-tp-example.toml` runs with your local config.
+
+Run the Pool:
+
+```bash
+cd roles/pool/config-examples
+cargo run -- -c pool-config-hosted-tp-example.toml
+``` 

roles/test-utils/mining-device/Cargo.toml

@@ -19,3 +19,8 @@ buffer_sv2 = { version = "1.0.0", path = "../../../utils/buffer"}
 async-recursion = "0.3.2"
 rand = "0.8.4"
 futures = "0.3.5"
+key-utils = { version = "^1.0.0", path = "../../../utils/key-utils" }
+clap = { version = "^4.5.4", features = ["derive"] }
+tracing = { version = "0.1" }
+tracing-subscriber = "0.3"
+sha2 = "0.10.6"