This post introduces a protocol for generating blocks with the right coinbases and miner payout transactions (called Unspent Hasher Payouts or UHPO). This block generation protocol is used by miners to generate blocks they will mine on. The protocol here focuses on the coinbase and the hasher payout transactions of the blocks, everything else will come straight from the bitcoin node’s getblocktemplate API call.

Block generation protocol

The protocols to generate a pool key, a new block and sign UHPO transactions go hand in hand.

When a new bitcoin block is discovered all miners need to immediately generate new blocks and start mining. Miners therefore have to locally generate the coinbase transaction and include a UHPO transaction paying out to miners.

Pool Key

Before we dive into the protocol, we introduce the notion of a “Pool Key”. A pool key is the public key that can spend the pool’s coinbase using a Threshold Signature Scheme. The pool key reflects the miners participating in braidpool and the key is generated by running a Distributed Key Generation scheme between the participating miners.

To generate a pool key we propose to run Pedersen’s DKG protocol and then generate a Schnorr threshold signature with the same participants. These protocols take time to execute and miners shouldn’t be made to wait for these protocols to finish before starting to mine new shares.

To eliminate this delay of waiting for a new pool key and a new signed UHPO transaction we propose a two phase protocol. The protocol will determine the new coinbase and the UHPO transaction to go into a block.

Two phase protocol

In the first phase, the miners generate a block that uses the pool key used in the block up to now. That is, the miners don’t immediately generate a new pool key. Miners also include the old UHPO transaction from the existing block. The second phase starts once the pool key has been generated. At this point, all miners generate new blocks with coinbases spending to the new pool key and UHPO reflecting the latest balance of shares generated by the miners.

The image below shows how the coinbase, UHPO transactions and new blocks are generated in two phases. B1, B2, B3 are the bitcoin blocks and BP1, BP2, BP3 are the braidpool blocks generated by any miner. Finally, CB, PK and UHPO are respectively coinbase, pool key and the UHPO transaction. CB (PK1) means coinbase spending to the pool key 1. BP2 (temp) implies a temporary braidpool block a miner mines on while the pool key for BP2 is being generated.

Temporary block generation by braidpool miners

Braidpool miner finds a block

However, what happens if braidpool miners find a block? We continue using the old pool key to generate the coinbase transaction. The new UHPO spends the previous UHPO and does not generate any outputs. That is, we don’t account for any of the recent shares in the new UHPO. This does not mean that miners won’t be paid for the recent shares, instead, as soon as the new pool key is generated all miners generate new blocks with a new coinbase and UHPO transaction that takes all the shares into account.


The protocol can be described at a high level as:

  1. Generate a temporary block which:
    1. Uses the existing pool key
    2. Depending on if the block is a braidpool block or not, the UHPO transaction:
      1. Remains the same - if the block discovered was a non-braidpool block.
      2. Spends the old UHPO and generate empty outputs - if the block is a braidpool block.
  2. Run a Pedersen’s DKG to generate a new pool key and a nonce for signing the new UHPO transaction.
  3. Generate a new block with the following:
    1. A new coinbase transaction spending to the new pool key.
    2. An updated UHPO transaction with updated balances for all miners, signed by the new pool key.

We are next working on a TLA+ spec for this protocol to help us find cases we overlooked.


This post briefly described a protocol to allow miners to continue mining while the pool’s membership and thus the pool’s key used for threshold signature changes. We are now working on a TLA+ spec for the protocol.