Radpool: Decentralised Mining Pool With Futures Contracts For Payouts

Protocol Design
5

Hi,

Thanks for taking the time to read through the proposal. I’ll include my replies inline and address other questions at the end.

Yes. In fact, we will need to support one of the optimisations suggested in the ROAST paper. Still calling it FROST Federation as the single round signing is what helps us scale to many MSPs.

Data Handling and Transparency

Nice reminder. We will need to prune the data in MSPs. The time decay for shares is something I was thinking will be a cliff. The reason for the cliff is - simplicity and it makes sure the shares between two blocks found are all available, for whatever PPLNS parameters we use.

specify desired authentication properties instead of specific username/password methods.

Yeah, I was leaving that out on purpose to make a decision just now. I think the standard usage out there is username/password on most pool servers. Therefore for keeping things easier for miners to switch I was thinking username/password might be the easiest.

How can uniqueness be accomplished? Using MSP pub key + mining username?

Yes. The requirement is that each miner essentially is given a random string as username by the MSP, or the MSP makes sure the one provided by the user is long enough.

Could latency/throughput FROST signing be a bottleneck?

The choice of FROST is driven by their single round signing. I did some analysis when thinking about using Belcher’s channels for payments. The message complexity is O(n^2), but round complexity is 1 - which is awesome. We still need to run experiments to measure performance of FROST Federation to know scaling limits.

Mining Fee Trends:

Yes. We’ll need to normalise the block templates proposed by each MSP and apply weights to the various shares mining for different block templates.

Other questions

  1. Lindell’s scheme is awesome. However, there is not open source implementation available,yet. I seriously toyed with rolling up my sleeves and working on it, but decided not to. Why is it awesome? Cause it is robust in the presence of failures, with three rounds. For robustness, instead, we use ROAST, which will have much higher message complexity, but easier to implement, as it is a messaging protocol, not the same as implementing cryptography :slight_smile: . If we see ROAST is being a bottleneck in the future and Lindell’s scheme is available, we could switch. For a functional MVP, we are going with FROST/ROAST.

  2. Dishonest MSP Handling - I essentially mean, someone not running FROST correctly or sending invalid shares. FROST has identifiable aborts, so we can identify the failing MSP and kick it out the next time. For invalid shares, each MSP knows the MSP is sending bad data. For other DDoS attacks etc, again, we can block and disconnect the MSP. For an equivocating MSP, the BFT broadcast detects the behaviour and we can leave that MSP out.

  3. 2000 block delay - I wanted to pick a period between 2/3 weeks. So an MSP joins, bring hash rate, but can’t participate in threshold signature unless it has been working correctly for 2/3 weeks, and then I randomly chose 2000 blocks. This prevents a large miner acting as an MSP and toying with the threshold signature, leaving, coming back and so on.

  4. Dashboard specifications - Not specified at all! I am thinking the first release will be a cli interface :slight_smile:

Thanks for the great questions

-kp

2 Likes