Bitcoin Contracts

These page shows the various bitcoin contracts used by the Radpool payout mechanism.

Coinbase

The coinbase pays the syndicate public key, called the syndicate public key, , is generated using the FROST KeyGen protocol as described in the Membership section of FROST Federation page.

This coinbase is spent using an interactive protocol between the MSPs when signatures for all miner DLC contracts have been generated by the syndicate. The interactive protocol is described in the MSP Protocols page.

Table 1. Coinbase
Inputs	Outputs

DLC Contracts Between Miner and MSP

Each miner enters a DLC contract with the MSP that funds the miner’s operations. In this section we describe the details of the bitcoin cointract.

Funding Contract

The miner and the MSP create a funding transaction that spends the MSP’s UTXO into a 2 of 2 multisig. The funding output between the miner and the is refered to as .

Table 2. Funding Transaction
Inputs	Outputs
MSP	2 of 2 MSP and Miner,

Nonce and Oracle Public Key For Miners

DLCs require an oracle to publish the public nonce ( value) and the public key ( value) for generating signatures that settle the DLC. These and values are published for each miner when the miner registers with an MSP.

We add a subscript to these values to highlight that they are generated for each DLC contract between a miner and the MSP. Therefore the contract between miner and MSP uses and values.

: The nonce for DLC contract is generated by MSP and published to syndicate using the reliable BFT protocol. The DLC specs point out that centralised generation of this nonce is acceptable.
: The public key for the DLC Oracle is generated using a DKG instance when the miner registers with an MSP. This requires that an MSP can request the syndicate to run a DKG instance for every miner that joins.

Contract Execution Transaction (CETs)

A number of CETs are generated by the two parties, matching the range of contract settlement terms. Each of the CET requires a signature from Radpool syndicate. The syndicate signs a message that is a representation of the exchange rate between the miner’s hashrate and the BTC offered by the MSP, let’s call this exchange rate , i.e. the exchange rate between the miner and the MSP .

DLC requires that the miner and the MSP generate a number of CETs corresponding to a range over the exchange rate. We write the exchange rate as . The CETs are signed by miner and MSPs with adaptor signatures that require an attestation from Radpool syndicate. The adaptor signatures use anticipated points generated using as the attestation.

The MSP generates CETs that it signs using the exchange rate as an anticipated point. CET is then sent to the miner who also adds its adaptor signature. Both the miner and MSP thus have a non-custodial UTXOs they can spend as soon as Radpool publishes an attestation for the miner’s hashrate.

Table 3. Contract Exection Transactions
Inputs	Outputs

Radpool Syndicate Publishes Attestations

The Radpool syndicate acts as the oracle for paying out miners and signs a message that corresponds to each miner’s hashrate over the last known periods. The oracle doesn’t know the terms of the contracts and therefore has to publish signatures for a well known range of expiry timestamps. For example, the Radpool syndicate can publish the hashrate of all miners over the last 1 day, 1 week and 1 month.

The signature is generated using the FROST Federation threshold signature. The threshold signature can be run in a single round as described section Federation Signature in Single Round.

The Radpool oracle publishes a threshold signature, , that corresponds to the following:

: known, as it is broadcast using a BFT reliable broadcast by the MSP when it generates .
: known, from the local store on all MSP, again thanks to a reliable BFT broadcast that provides consistent information dispersal.
: not known, is the private key corresponding to the public key .

Radpool is thus able to perform the functions of a DLC Oracle without any single party holding the private key, and requiring a minimum threshold number of parties to co-operate.

Rollover Miner Payout

The miner can spend the contract output without asking the MSP or the syndicate to sign the transaction. However, spending a CET and then another transaction to spend the non-custodial UTXO on chain each time the miner earns a payout does not scale. Such a construction will use up block space per miner for each expiry period.

Instead, we propose that miners and MSPs rollover their balance into the next DLC contract for the next payout period. The roll-over will work similar to the way LN contract state is expired to be replace with a new one, as describe in the Roll-Over Contract Transaction section.

We modify the CET transactions such that the miner and the MSP can agree to revoke an older state as they build CETs for the new state.

Note that the miner is paid by the MSP and therefore has no incentives to broadcast an older CET that pays it less than the latest CET. Therefore the Miner’s CET transaction doesn’t need to be revoked. We only need to add the condition in the MSP’s CET to allow for revocation.

When the MSP sees the oracle’s signature to settle a CET, it immediately creates a new DLC contract for the next epoch, and reveals the revocation key to the miner for the older CET. The miner continues to work with the MSP under the new DLC contract since it knows the revocation key for the older state. The revocation key is published using the semantics of the per commitment secret and the revocation base point just as used in Bolt #3’s key revocation section. In our case, only the MSP exchanges the per_commitment_secret with the miner to allow the miner to sign a revoked transaction if it sees an old commitment transaction has been broadcast.

In the following, the miner provides the revocation_base_point and revocation_base_secret, while the MSP provides the per_commitment_point and the per_commitment_secret. The per_commitment_secret is handed to the miner by the MSP when the MSP revokes and older CET.

revocationpubkey =
  revocation_basepoint * SHA256(revocation_basepoint || per_commitment_point) +
  per_commitment_point * SHA256(per_commitment_point || revocation_basepoint)

revocationprivkey =
  revocation_basepoint_secret * SHA256(revocation_basepoint || per_commitment_point) +
  per_commitment_secret * SHA256(per_commitment_point || revocation_basepoint)

We show the MSP CET transaction next where the MSP output has a time delay. This allows a miner to claim the CET in case the MSP tries to broadcast an older CET. This solution is might seem problematic, as the MSP can force the miner to broadcast an older state and thus has a underhanded way to get out of the latest DLC contract. However, we avoid that by requiring that the is longer than the expiry of the DLC expiry. This allows a miner to keep submitting hashrate to Radpool and get a valid signture from the Radpool Oracle to settle the latest contract.

Table 4. Contract Exection Transaction for MSP With Revocation
Inputs	Outputs

With the updated CET construction, if an MSP broadcasts a revoked CET, the miner will be able to take all the amount in the MSP’s output.