Payout Mechanism

This is an important requirement and is motivated by the scaling issues faced by P2Pool (1, 2) where the miner payouts competed with other transactions for block space.

Chris Belcher proposed a solution that required hubs to co-ordinate the payouts. We extended this idea as an alternative proposal for Braidpool. The proposal uses unidirectional payment channels and removes the dependency on predicting miner payouts by using a P2P DAG of shares. In Radpool, we propose replacing the hubs with a syndicate whose members act as Mining Service Providers. These MSPs provide liquidity, manage payouts as we explain later and maintain a consistent replicated set of shares received from all miners.

A miner should be able to leave the mining pool with all the reward that they have earned, without requiring permission from any MSP. There are solutions, for example Braidpool’s UHPO model where miners need to send a request to the pool to obtain their payout. With unilateral exits, a miner can leave any time and if the syndicate becomes unreachable, the miner’s payout is firmly within their control.

A centralised co-ordinator that makes payouts is an antithesis to a decentralised mining pool. Often there are arguments that a mining pool can make payouts over lightning network, however, all the designs in operation today require a centralised lightning node operator to make the payouts. Which means, that if the lightning node misbehaves for any reason, the miners are directly impacted. In Radpool, we make payouts in a way that does not depend on a single entity. As long as a threshold of parties are behaving correctly, miner payouts are updated and the miner can later unilaterally exit at any time.

With increasing adoption of FPPS instead of PPLNS, Radpool should support an equivalent reward payout scheme where a miner and a capital provider can agree on the exchange rate and expiry. Once the contract is agreed upon, Radpool’s syndicate should act as an oracle to settle the contract and neither the miner nor the MSP should be able to block the contract execution.

When a miner joins the pool, the request is sent to an MSP the miner is connected to. The MSP then triggers a miner registration protocol, for the Syndicate to act as an Oracle for payout contracts between the miner and the Syndicate. As part of the registration process, the miner submits a public key to the MSP. This key is used to generate the DLC payout contracts between the MSP and the miner. The miner also creates a username and password for authenticating future stratum messages. This username is also used enable verifiable ownership of shares as described in Verifiable Share Ownership section.

In response to request from miner to join the pool, the Radpool Syndicate runs a single instance of DKG to generate the public key to be used for signing the DLC contract execution transactions. See DLC specs for details on these transactions. The public key generated by this DKG instance is the value for the miner .

The public nonce for the miner, , is generated by the MSP and broadcast to the syndicate. To prevent a DDoS attack where an MSP repeatedly runs DKG instances, the MSP maintains a queue of miner join requests, and runs a limited number of DKGs every fixed time period. The list of membership requests is replicated consistently by using the BFT reliable broadcast and miner join requests are handled by running a round robin request selection over MSPs. We avoid the requirement of a totally ordered broadcast which will add to communication and protocol complexity.

Note that the same public key is used for all future DLC settlements for miner , as long as the syndicate membership doesn’t change^[1]. The paper also specifies that the nonce should not be re-used and can be generated by a single party. We are able to avoid running a DKG round to generate the nonce for each miner by having the miner’s MSP generate one for the miner. The MSP broadcasts the nonce value to all the other MSPs using echo-broadcast to be sure all MSPs have received the nonce.

The two values and are now available to all MSPs. The miner is then sent these values by their MSP. The miner will validate that these values have been received by other MSPs. This is possible because all MSPs allow connections and serve the public mining information. Note this functionality of the miner’s client to the Radpool syndicate doesn’t have to be on site for the miner or always online. The functionality is a wallet like application that the miner runs for registering with the MSP and managing payouts received from the MSP.

With the public values now available, the syndicate can sign the hashrate for a miner to settle that miner’s DLC contract payout. Before we describe how this works we describe the terms of contracts.

Once the public values and are published, the miner and its MSP agree on the terms for the payout contract.

As required by DLC, the Expiry will be fixed, but there will be a number of combinations of (Hashrate, Amount) that the MSP and the miner will agree to. Here’s an example list, showing a contract where hashrate more than 1PH/s will pay the miner a million sats, and lower than 0.8 PH/s will pay nothing, and the intermediate steps will pay intermediate values. Note this list shows the contract terms at a high level, Radpool will use the exponent/mantissa optimisation proposed in the DLC paper to generate the full list of transactions necessary to execute the contract terms.

The funding transaction between the miners and the MSP is funded by the MSP and locks the output as a 2 of 2 multisig. MSP and the miner thus agree on the txid and the output that will fund the payout contract.

Before the MSP signs the funding transaction, the miner creates a refund transaction that spends the funding transaction, returning the entire amount to the MSP. The output of the refund transaction is timelocked to extend beyond the contract expiry. The refund transaction allows the MSP to claim back the funds in the case that the miner leaves the pool without claiming the contract payout.

Contract execution transactions (CETs) spend funding transaction outputs with the amount BTC. This amount funds the contract and is the maximum that the MSP can payout to the miner when the contract settles. The amount needs to have a margin of safety and we discuss that later in the Capital Requirements and Fees section.

The CETs are signed by both the MSP and the miner, however, both the signatures are Adaptor Signatures that are can be decrypted when the Radpool syndicate publishes an attestation for the miner’s hashrate. We use the adapater signature technique developed to circumvent weaknesses in the initial DLC paper and described in detail by Kuwahara et. al..

The Radpool syndicate publishes miner hashrate attestations at fixed time intervals. The syndicate is never aware of the contract exchange rates between the miners and the MSPs. The syndicate is only aware of the hashrate of the miner over a given time period. At the fixed time interval, all the MSPs calculate the that has to be paid to a miner by looking at data locally available with them. They then run an instance of the threshold signature scheme to sign the message. The syndicate has to be sure to use the correct set of values when publishing the signature. The values have to be tracked for the current contract being executed. The expiry and the miner public keys help track this as the syndicate generates oracle signatures.

Once the syndicate has published a signature attesting to a miner’s hashrate, the miner can spend the output at any point in time.

The miner and the MSP enter a contract for each expiry period. For example, if a miner wants to be paid on a weekly basis, they enter into a DLC contract at the start of each week. So a sequence of contracts can look like the table below. Each of the contract will have the full range of CETs that pay the miner a set amount of BTC for the various values of hashrate it generates.

Each week’s contract is created just before the expiry of the previous week’s contract. The MSP calculates the BTC amount to pay for the hashrate and offers a contract. The miner can provide configuration options to set the minimum payout it is willing to accept for the hashrate. How the MSP calculates the BTC to pay for hashrate is not addressed here. We expect there will be extensions that offer various means and models to compute this exchange rate. MSPs are free to provide any algorithm to agree on these exchanges rates - it is up to the miner and MSP to agree on the payout contracts. Radpool simply publishes attestations that settle any contracts that the miner and MSP have agreed on.

The payout mechanism allows for roll-over of both the transaction types listed above. As discussed earlier, miners can roll-over the their payouts to reduce the on chain fees they need to pay. There is a possibility here to move miner payout DLCs into LN contracts. We leave this optimisation out from this initial proposal as it is a well understood technique, mentioned in the initial DLC paper.

In the same way as miners roll-over their payouts, the MSPs can also signal to the syndicate to aggregate their payout until a minimum balance is reached. This is a choice the MSP can make to lower on chain transaction fees. Again, we leave such optimisations out of the current proposal.