Some comments on this proposal.
TL;DR: The differences between this Radpool proposal and my Braidpool proposal are:
- The use of a fixed FROST signing federation (radpool) instead of a dynamic one (braidpool).
- Having the FROST federation be composed of share-buying entities (radpool) instead of miners (braidpool).
- Having share-buyers in control of block templates (radpool) instead of miners (braidpool)
Everything else is identical. Kulpreet has been working on FROST signing and I have been working on the Braid accounting and payouts. I don’t see any reason that this can’t be one project. At any rate I intend to keep working with Kulpreet and use his FROST code for Braidpool’s dynamic federation.
In more detail:
- Using a syndicate of MSPs will result in a highly political process around allowing MSPs into the signing federation. By comparison, Braidpool will use an open dynamic federation composed of miners who have recently won blocks.
- Since MSPs decide block templates, this presents a smaller number of entities to attack for those that want to censor transactions. Furthermore the profit motive for constructing block templates is poor – most jurisdictions make it legally risky to perform this task, which is why OCEAN and Braidpool move block template selection to the edges (individual miners) maximizing the number of entities that must be attacked to accomplish censorship. Block template creation is not logically related to participating in the financialization of mining. Note that attempting to censor in this way is a mis-application of laws intended for banks which have three functions they perform that Bitcoin miners, nodes, and MSPs fundamentally cannot: beneficial party identification, transaction blocking, and asset seizure. We should be simultaneously lobbying against this mis-application of laws. Centralizing around MSPs will result in the same situation as currently happens in Ethereum: there will be two types of block producers, “compliant” and “MEV”, neither of which we want. Share buying is a logically distinct operation from block template construction and I don’t find it necessary or desirable to conflate the two. Today’s centralized pools are already conflated share-buyers and block-template-deciders and we know what that looks like.
- The use of PPLNS implies significantly higher variance than Braidpool, depending on N. One can regard Braidpool as PPLNS with N=2016 (the fixed difficulty adjustment window) which enables simple pricing of hashrate derivatives. With any other PPLNS scheme such as used by OCEAN (N=8) or Radpool, pricing and trading of options and future (share transfer to a risk-taker) is significantly muddied since different shares within the same difficulty adjustment window will have a different price. This incentivizes pool hopping – switch to Radpool or OCEAN when the share price is high and switch away when the pool’s luck drops. It also makes the creation of standardized derivatives markets nearly impossible.
- The share accounting system was not described. Braidpool will provide this in its DAG. If these end up being separate projects, I invite Radpool to use it.
But some praise:
- I think using DLC’s for share buying is a good idea and have been investigating it for Braidpool too, to emulate FPPS.
- Even if @jungly wants to pursue this as a separate project from Braidpool, I think much of the FROST signing federation code and possibly share accounting (if he wants to put them in a braid) can be shared. I’d rather have two decentralized mining pool projects than zero and I will finish Braidpool.
I don’t know why @jungly proposed a separate project, but I think a big part of his motivation is that he thinks miners won’t want to run Bitcoin or Braidpool nodes. I’ve heard both opinions from miners (that running Bitcoin nodes is not a problem and “too hard”). Time will tell but I think this is important to move block template selection to the edges and OCEAN is seeing success with DATUM.
Finally let me correct some misconceptions:
“Braidpool’s UHPO model is an example where a miner needs permission from a threshold of miners to exit with their payout.” – Braidpool will not require permission to exit. All shares will be paid automatically at the end of a difficulty adjustment window and any miner in the network can broadcast this transaction. The rules around the resulting UHPO transaction are decided by consensus and proportional distribution of BTC according to submitted shares. If the pool fails to sign an Eltoo update or UHPO update, the last known-good set of payouts is already signed and can be broadcast by any miner. From that point on any hashrate pointed at the pool will fall back to solo mining.
The scale of Kaspa relative to the number of nodes on Bitcoin is not a valid comparison. This has to do with the desirability Kaspa as an asset, not the scaling constraints of their consensus protocol.
The security model of FROST signing proposed in Radpool is identical to what I proposed for Braidpool. Signing nodes are connected point-to-point by revealing their (encrypted) IP information to other miners in the signing federation (but not to anyone else). Thus all the security proofs for FROST hold.
Finally finally, there are fundamentally two different kinds of entities involved in the FROST federation: miners and share-buyers. In the presence of both, it doesn’t make sense for the signing federation to be composed entirely of one or the other. Miners shouldn’t be in full control of whether their contracts settle and neither should the share buyers. Therefore the logical conclusion is that the signing federation should be composed of BOTH, with miners represented by their hashrate, and share-buyers by their locked financial commitment, proportionally. I will modify the Braidpool proposal to include both. Likely using DLC’s.
Lastly, if you’re interested in either, please join the Blockchain Commons meeting on Dec 4 to hear Kulpreet talk about his FROST federation!
Cheers, – Bob