There are a few differences between Braidpool and Radpool proposals
- Consensus - Radpool does not need one, Braidpool needs consensus on transactions/beads/blocks at the base layer itself. Radpool only needs BFT broadcast that FROST federation needs anyway.
- Timeliness concerns - Radpool does not do consensus and therefore does not have concerns about reaching the consensus in a given time frame. FWIW, I think we should build delay tolerant protocols.
- FROST Federation - Radpool federation membership explicitly defines how miner hashrate decides federation membership. Braidpool requires miners to get lucky to find a block for joining the federation. I think hashrate is enough and is more inclusive than finding blocks.
- Payout mechanism - In Radpool a single miner can exit at any time, with Braidpool the miner has to wait two week period in the worst case, or request permission for an early exit.
- Futures payout mechanism - Radpool’s payout primitive is a future’s contract using a DLC. Braidpool needs to figure out how the futures contracts will work.
- Miner onboarding - In Radpool, a miner signs up to an MSP and is done. In Braidpool miners need to run a fair few services to get going.
- Network Topology - Radpool ends up with a point to point network of MSPs and miners talking only to MSPs. Braidpool is a p2p network across all miners.
For what is worth, the syndicate in Radpool is built by MSPs who bring both the required hashrate and liquidity they provide to fund DLCs.
Execution Risk
The biggest reason I am pitching Radpool as a separate project is execution risk with Braidpool.
Braidpool proposes a consensus protocol that is not proven to work or to scale - especially if we don’t use Kaspa’s DAGKnight protocol. I get DAGKnight, my PhD thesis was on a DAG based consensus protocol back in 2006. I remember how much effort it took me to implement a consensus protocol. Implementing a new consensus protocol that can scale to thousands of nodes is risky. I suspect at scale DAGKnight’s block rate will slow down and so will Braidpool’s. What will that mean for Braidpool, where we are very focussed on fast block times, I don’t know. It could work smoothly. But it is a risk.
Radpool eliminates the need for consensus. Radpool explicitly avoids new cryptography or distributed systems protocols. With Radpool, we take well understood protocols and put them together to provide a mining pool that improves blocktemplate decentralisation and offers decentralised FPPS.
Response to Bob’s Comments
syndicate of MSPs will result in a highly political process
Syndicate membership is explicitly defined by the hashrate the MSP brings to the pool. Miners vote with their hashrate.
smaller number of entities to attack for those that want to censor transactions
Some miners want to and can build block templates. Others don’t want to. Radpool enables both. Some MSPs will run SV2, some will run SV1. Miners will choose how they want to work. MSPs will support both SV1 and SV2 - good old SRI has both!
pricing and trading of options and future (share transfer to a risk-taker) is significantly muddied
Radpool’s future contract is very simple and defined between two parties - MSP and Miner. MSP agrees to pay miner X BTC for Y Hashrate produced by Z date. All three parameters are independently decided for each contract by the parties involved. Braidpool’s future contract system is not yet clear to me. I tried to define something using single use seals for Braidpool a while back, but Braidpool didn’t go that route.
The share accounting system was not described.
I’ll add a section on this.