Braidpool - UHPO Payout Mechanism

braidpool_uhpo_payout_mechanism.adoc

Braidpool Payout

Goals of Braidpool’s Payout Mechanism

1. All miners are rewarded for their share of PoW contributed.

2. The payout construction scales sub-linearly with the number of miners participating in the pool.

3. A miner should be able to cash out unilaterally without requesting permission from another party or a group of parties.

Unspent Hasher PayOut (UHPO) Mechanism

There are three main transaction types and a threshold signature scheme that together constitute the UHPO mechanism. In this document we describe the transaction types and how they relate to each other. We only touch upon how the threshold signature scheme is used, but leave the details of it for another document. We also do not describe the protocol for generating these transactions.

Transaction Types

1. Coinbase Tx - This is the coinbase transaction included by miners in their block templates. Each miner will have a different coinbase transaction, as we see later.

2. Payout Update Tx - This transaction that spends the previous confirmed payout update transaction and the latest coinbase transaction. This transaction has a single output that will be spent by the next payout update, or in case of failures by a settlement transaction.

3. Payout Settlement Tx - This transaction spends the single output from the payout update transaction. The output this transaction spends is time locked, giving the pool time to generate a new valid update transaction, broadcast it and also confirm it. If a new update transaction is not confirmed within the given timeout, this settlement transaction will be broadcast and all miners receive their payouts.

The figure below shows a successful run the pool, with three coinbase transactions generated at height 1, 2 and 3. The figure also shows payout update transactions that are broadcast and confirmed. Settlement transaction are constructed and are not broadcast in the exampl as their inputs are already spent by the next update transaction.

Payout update and settlement transaction are created and broadcast as soon as there is a new coinbase is availble in a block mined by braidpool. That is why coinbase@height is spent by Payout update@(height+100).

Figure 1. Successful Series of Payout Update Transactions

In the image above we see all the three types of transactions.

Using Eltoo Construction

The UHPO model uses the eltoo construction of creating update and settlement transaction, where each new update transaction spends the previous update transaction before the settlement transaction is broadcast. If a new update transaction is not broadcast then the settlement transaction will be broadcast to close the series of payout updates.

Coinbase Transaction

Each coinbase transaction has a single output which will be spent by the pool generating a threshold signature, or it will be spent after a timeout period. The latter spend is broadcast by the miner that generated the coinbase as it has the private key to spend the timeout condition.

In the image above, the three coinbases are generated by Alice, Bob and Alice respectively.

Payout Update Transaction

The payout update transaction has at least a coinbase ouput as an input and will have a second input for second payout update onwards.

In the image above, the payout update transactions are titled "Payout Update @ 101", "Payout Update @ 102", and "Payout Update @ 103". The number after "@" suffix is the height at which the update transaction is broadcast.

Each miner will generate the same payout update transaction, so there is no need to disseminate the message that the threshold signature scheme has to sign. The membership that will participate in the threshold signature is also known from DKG run when the poolkey for the coinbase was successfull generated.

Questions

1. Do all miners broadcast the update transaction once it is signed?

2. What fees do they pay? The pool miners have to guarantee the update transactions are included in a block they might not be mining - otherwise the settlement transaction will become spendable, and miners will broadcast it expecting a failure.

Settlement Transaction

The settlement transaction spends the only output of the payout update transaction. The miners all work on creating and signing the settlement transaction when they generate the update transaction. However, this will be a separate concurrent run of the threshold signature protocol to sign the settlement transaction.

Miner Cashouts

Miner cashouts require permission from the pool. When a miner wants to cashout, it broadcasts a message to the pool’s p2p network and the pool members generate the next Payout Update transaction to include the cashout for the miner.

As seen in the image below, Alice is able to cashout because the "Payout Update @ 103" is created such that Alice’s balance is deducted from the payout’s pool output, and a second output is created that Alice will spend later.

Figure 2. Successful Miner Cashout

Failures

If the pool fails to generate an update transaction in time, the last known settlement transaction will be broadcast by all members. The failure results when the threshold signature fails, or the pool is unable to get a new update transaction confirmed on chain.

Figure 3. Failure to Confirm a New Payout Update

Questions

1. When the pool is small these update and settlement transactions can be censored and fail to confirm in time. This will result in the pool disbanding and a new pool starting afresh.

2. Only a single miner gets all the reward for the last successful update transaction. In the image above, Alice gets all the reward for "coinbase@3". Is it possible to address this?

Challenges

Apart from the questions pointed to in the above sections, there are some other challenges that we note here.

1. Group membership We need to track the pool membership so that we can run the threshold signature protocol. Group membership has a reduction to consensus. We determine the group membership from the share dag. Does this leave us vulnerable to an attack? We need to look into this, especially since FROST will restart the threshold signature protocol on a single failure.

2. Concurrent protocol The protocol to build coinbases, update transactions and settlement transactions is a multi party concurrent protocol. This needs to be modelled and evaluated with tools like TLA+.

3. Miner cashouts and Unilateral exits The protocol requires a threshold number of miners to agree that a miner is cashing out. A miner can unilaterally exit only if there is a catastrophic failure. It will be nice to explore if how this model can support unilateral cashouts by miners.

uhpo-failure.png

uhpo-success.png

uhpo-with-cashout.png