We propose a solution to use proof of work to signal rounds needed for implementing DKG/TSS protocols.

Problem: DKG/TSS Need Definition of Rounds

When miners participating in braidpool build a block, they need to build a coinbase transaction spendable by a threshold of participating miners. They also need to sign the hasher payout transaction (the UHPO) to update the reward distribution for miners. Braidpool needs to run a DKG protocol to obtain a public key to use in the coinbase and then a TSS protocol to spend the previous coinbase into the UHPO. See Generating pool key and blocks to mine for discussion on the protocols required.

DKG protocols with security proofs require the definition of rounds to run the protocol. These protocols include FROST and Pedersen’s DKG. There is some work being done to provide provable secure DKG for asynchronous networks, and this research is still in early stages.

The rounds for these protocols can be defined under the partially synchrony assumption for the communication network. However, bitcoin and braidpool do not assume partial synchrony. In other words, braidpool does not assume an upper bound on message delays and therefore can’t define rounds in terms of physical time.

The Proof of Work Clock

We propose using the proof of work generated by miners as a clock to signal the change in rounds.

In bitcoin, when miners generate weak blocks using their chosen difficulty they eventually stumble upon a weak block that matches the current bitcoin difficulty. The bitcoin network adjusts this difficulty every 2016 blocks to target the inter block time of around 10 minutes.

We take the same approach of using proof of work with difficulty adjustments to define rounds for executing DKG and TSS protocols.

We begin by defining the inter-round period of $n$ seconds. This enable DKG/TSS protocols using FROST to finish $3*n$ seconds. In this post we leave out what this $n$ should be, it could be anywhere between 10 or 60 depending on the tolerance we aim for completing a FROST execution.

Rounds Protocol

We define the protocol to define rounds as follows:

  1. Select a target round period of $n$ seconds. This is a well known parameter to all nodes - either hard coded or as a configuration parameter.
  2. We define a weak block as a “round block” if it meets the round difficulty target $d$.
  3. A round block is accepted as a round block by a miner if it meets all the usual weak block validation requirements and also has been received within $n$ seconds of being mined by the miner. That is if round block is stale the receiving miners don’t trigger a round change. [See note 6 on the point about synchrony in bitcoin.]
  4. The difficulty $d$ is adjusted every $R$ round blocks just as the bitcoin difficulty is adjusted, with the target time of $n$ seconds.
  5. We only consider round blocks found by miners whose hash rate has not changed by a certain percentage over the last $R$ round blocks. [See note 5 on rapid difficulty adjustments].
  6. A node switches to the next round of the DKG once a round block is received by the node and is inserted in a node’s DAG.
  7. Each DKG/TSS message must only be delivered to the DKG/TSS module at a node once all messages dependencies in the DAG for that message have been received. This enforces all nodes to have the same view of the DAG up to the DKG/TSS message before acting on it. If a node attacks the DKG by sending messages out of rounds, the DKG/TSS protocols handle such an attack.

Notes

  1. The use of round blocks doesn’t impose restrictions on running a single DKG/TSS executions at a time.
  2. The clock is not external to our system, i.e. we have a way to define rounds without depending on an external clock.
  3. There is no agreement required between nodes for the exact “physical time” when rounds start and finish.
  4. All nodes switch to next round at the same logical time derived from the DAG.
  5. We avoid rapid difficulty adjustments by looking at weak blocks only from miners whose hash rate hasn’t changed by a more than an upper bound over the last $R$ round blocks. This mitigates an attack by a malicious miner to rapidly change their hashrate to destabilise the rounds and thus prevent completion of DKG and TSS execution.
  6. Even if we depend on loosely synchronised clocks like bitcoin does, the communication model in braidpool is still an asynchronous communication models. See Synchrony in bitcoin for a longer discussion.