Attacks

Each MSP builds templates for the miners working with it. The problem of block withholding attack is not made worse like it is in the case of Braidpool where miners build their own block templates. Each MSP validates all the shares it receives from the miners and from other MSPs. That is, a share is earmarked to be rewarded only if it passes share validation against the block template generated by the MSP.

The reward calculation algorithm deducts rewards from all miners to give a bonus to the miner that found the block. As shown by Zhihuai Chen et. al. such an approach discourages block withholding attacks.

When a miner sends their share to a MSP, the member signs the shares before broadcasting to the entire syndicate. This identifies shares with the MSPs that brought the hashrate to the pool.

To prevent anyone from joining the syndicate by bringing in capital, we require that MSPs also bring in hashrate to the pool. Further, to resist sybil attacks by anyone joining the syndicate, we limit the threshold participation to the members that bring the top 60% of the hashrate as explained in Membership section.

An MSP can bring a lot of hashrate to Radpool and then quickly take it away suddenly. Such an MSP could be another pool on bitcoin that wants to attack Radpool. The attack seems to work because it seems like as the Radpool hashrate increases the miners payout also increases. However, this is a fallacy, as the miner is always paid based on its own hashrate, not based the Radpool hashrate. Even if the total amount earned by Radpool increases due to an increase in the hashrate, the amount paid to individual miner is only related to the individual miner’s hashrate. When Radpool’s hashrate increases, the variance in the payouts to MSP reduces. The miners are always paid at contract expiry as agreed between the MSP and the miner.

An MSP can stop sending stratum work messages to a miner, disabling a a miner’s ability to submit work to the pool. The MSP could be another pool trying to attack Radpool by trying to hurt the miners on the pool, or it could be an MSP that realises it is going to make a loss when the latest DLC contract with the miner is settled. Remember, the DLC contract is settled by the Radpool syndicate acting as an oracle.

The most robust way to avoid this attack is to ask miners to run a proxy, that sends the hashrate to all MSPs in the syndicate, and to allow the proxy to change the stratum server. However, such an approach has two drawbacks, 1) we want to avoid requiring miners to run a proxy, 2) sending stratum submit messages to all MSPs will result in a linear increase in the bandwidth required. Both these problems affect the long tail miners that Radpool wants to make sure are not excluded from the network.

Instead, to avoid the attack, we allow a miner to submit work to the pool using another MSP. ASICs machines allow adding multiple stratum URLs, and our solution is that the miner has access to the entire list of active MSPs along with attributes defining their availability and performance. This will allow a miner to choose backup MSPs that it can provide directly to their ASICs or any proxy services they use. The backup MSPs have a vested interest in keeping the hashrate on Radpool and therefore can step in to facilitate work for a miner.