Replicate Share Data Across Syndicate

We need to replicate PoW shares from all miners at all other MSPs. This provides all MSPs with a consistent view of the shares which in-turn enables all MSPs to compute the exact same reward payouts for miners. Replicated data also helps miners and other interested parties to verify the functioning of the mining pool.

The following data is broadcast by an MSP to all other MSPs

  1. Block templates generated by the MSP - this enables other MSPs to validate any future shares and also to assign attribute shares to an MSP.

  2. All mining.notify messages sent by MSPs to their miners.

  3. PoW shares submitted by miners using the mining.submit stratum message.

To provide the data replication, we run a reliable BFT broadcast algorithm proposed by Cachin et. al - Asynchronous Verifiable Information Dispersal. The protocol replicates data across point to point nodes with low communication complexity requirements while tolerating byzantine failures.

At this point, any nodes that connects to the network can receive the replicated data. However, an MSP MUST replicate all data with other MSPs that are part of the syndicate member, replication to the other nodes is optional. If an MSP fails to participate in the BFT reliable broadcast, the MSP’s shares won’t be included in the pool’s reward calculation. The Syndicate will exclude the MSP from the next round of DKG. More on this later.

Given all the PoW shares are replicated across the syndicate, it is important the each share can be identified as mined by a miner for a certain MSP. By supporting verifiable ownership of shares, we can replicate the data across the syndicate and each MSP can then verify that who mined the share and for which MSP.

Verifiable Share Ownership

As described above mining data needs to be replicated across the syndicate. mining.submit and mining.notify messages are broadcast to all MSPs in the syndicate. We therefore need to assign ownership to these messages such that the ownership can later be validated. We depend on the mining.notify.jobID and the mining.authorize.username fields to assign this ownership. We also use the MSP’s well known public key that is used to determine the MSP’s node id. This is similar to the approach taken in LN to identify peers.

The jobID is constructed as a hash of the concatenation of 1) miner username, 2) the sequence_no used by MSP for the miner and finally 3) the MSP public key. The jobID therefore can be proven to be an MSP job and can now be broadcast to the syndicate with verifiable ownership. To prove the ownership of mining.submit messages the MSP provides the username, sequence_no with each broadcast. The receiver knows the MSP public key and therefore can validate the ownership of mining.submit.

The miner username should be unique across the network and for the same, we recommend using a random number seeded with current time to be the miner’s username. The username is generated once by the Radpool miner dashboard for the miner to use across registrations to MSPs.

Backup MSPs

We note in the next section on Denial of Service Attacks that miners should configure their systems to submit shares to backup MSPs. Miners can push their configuration to their ASICs machines or can use a proxy - if they are using one. The proxy is not a requirement to participate in Radpool.

When the primary MSP is unavailable, the miner can switch to the next MSP in their list because they have registered with two additional MSPs acting as a backup. These MSPs are configured in their setup to interact with the alternative MSP.

The ownership verfication still allows Radpool oracle to compute the hashrate posted by a miner. As shown earlier, each share broadcast to the syndicate has enough information to verify the share is generated by a miner.

Why Will MSPs Step Up?

The back up MSPs step up for an MSP that is unavailable as it is in their favour to make sure the Radpool hashrate doesn’t go down. Backup MSPs don’t need to expend too much compute here. They are building block templates and sending stratum work messages to other miners. They are also validating all the shares being broadcast to the Radpool syndicate, so there is no additional work to step up and act as a backup for an MSP temporarily unavailable or trying to attack Radpool.