Skip to content
This repository was archived by the owner on Sep 10, 2025. It is now read-only.

Commit 4b628c1

Browse files
Merge pull request #252 from DankMiner/dev
SharedRelayReadMe.md
2 parents c04221a + e9847c9 commit 4b628c1

File tree

1 file changed

+89
-0
lines changed

1 file changed

+89
-0
lines changed

ShareRelaysReadMe.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
## ShareRelaysReadMe.md
2+
3+
**Composed by:** DankMiner
4+
**Inspiration:** Based on insights and studies from the miningcore GitHub repository.
5+
6+
---
7+
8+
### Purpose
9+
10+
The overall goal is to enable a setup where **multiple stratum servers** work in tandem with a **shared primary server**. This architecture allows us to:
11+
12+
- **Distribute load:** Different servers can handle mining requests concurrently.
13+
- **Increase reliability:** If one stratum server goes down, the others continue to operate and feed data into the primary server.
14+
- **Enhance security:** A shared encryption key ensures that communication between all parts of the system is protected.
15+
- **Centralize management:** The primary server aggregates data from individual stratum servers, which simplifies monitoring and control.
16+
17+
---
18+
19+
### Configuration Details
20+
21+
#### On the Primary Server
22+
23+
In your primary server’s configuration file—typically `config.json`—you’ll add the section `"shareRelays"`. This is an array containing the details for each stratum server.
24+
25+
**Example:**
26+
27+
```json
28+
"shareRelays": [
29+
{
30+
"url": "tcp://207.244.250.69:6000",
31+
"sharedEncryptionKey": "password"
32+
},
33+
{
34+
"url": "tcp://154.53.39.114:6000",
35+
"sharedEncryptionKey": "password"
36+
},
37+
{
38+
"url": "tcp://66.94.123.222:6000",
39+
"sharedEncryptionKey": "password"
40+
}
41+
]
42+
```
43+
44+
**Steps:**
45+
46+
1. **Replace the URL:** For each entry, change the IP address (`207.244.250.69`, `154.53.39.114`, `66.94.123.222`, etc.) with the actual IP address or domain name of the stratum server.
47+
2. **Update the shared encryption key:** Change the value for `"sharedEncryptionKey"` from `"password"` to your unique key. This shared key is critical for ensuring that both the primary and stratum servers can authenticate each other securely.
48+
49+
#### On Each Stratum Server
50+
51+
Similarly, on each individual stratum server, you must configure a corresponding section, labeled `"shareRelay"`. This tells the server where to publish its data and what key to use for secure communication.
52+
53+
**Example:**
54+
55+
```json
56+
"shareRelay": {
57+
"PublishUrl": "tcp://207.244.250.69:6000",
58+
"SharedEncryptionKey": "password"
59+
}
60+
```
61+
62+
**Steps:**
63+
64+
1. **Update the Publish URL:** Change the `PublishUrl` to reflect that server's public IP address or hostname.
65+
2. **Ensure Matching Encryption:** The `"SharedEncryptionKey"` must match the encryption key specified on the primary server for that relay. This ensures that both ends can securely exchange data.
66+
67+
---
68+
69+
### Why Do We Do This?
70+
71+
1. **Centralized Data Collection:**
72+
By linking multiple stratum servers to a single primary server, mining data is gathered and consolidated in one place. This makes it easier to analyze performance, detect issues, and manage operations without having to access each server individually.
73+
74+
2. **Enhanced Security:**
75+
The use of a shared encryption key across all communications is vital. It ensures that data transferred between the servers is encrypted, thwarting unauthorized access and potential tampering. This is especially important in mining operations where sensitive data is exchanged.
76+
77+
3. **Load Balancing and Fault Tolerance:**
78+
Having a distributed network of stratum servers can handle a larger volume of mining requests and distribute the load evenly. If one server encounters problems or needs maintenance, the primary server continues to receive data from the remaining nodes, ensuring continuity.
79+
80+
4. **Scalability:**
81+
This configuration is scalable. As mining operations grow, additional stratum servers can be added with minimal adjustments—just update the primary server’s configuration and add a corresponding `shareRelay` on the new node. This seamless scalability helps accommodate growth without significant re-engineering.
82+
83+
---
84+
85+
In summary, this design is a robust method to manage multiple mining servers. By ensuring a secure, scalable, and centralized approach, you maintain high efficiency and security across your mining network. Additionally, this system design helps in balancing loads and provides redundancy, which is crucial for uninterrupted mining operations.
86+
87+
---
88+
89+
**Extra Insights:** If you’re looking to further optimize your mining setup, consider integrating automated monitoring tools on your primary server. These tools can alert you immediately if a relay goes offline or encounters errors, allowing for rapid intervention. Moreover, periodically updating your encryption keys and rotating them on a scheduled basis can add an extra layer of security to your communication channels.

0 commit comments

Comments
 (0)