Providing futures contracts for hashrate has proven to be a challenge in the current mining ecosystem. Hashrate tokens by Blockstream, poolin and binance are some of the early attempts to provide financial contracts for miners. The problem with these contracts is that they are opaque and can only be traded OTC - often times only useful for the pool participants. In this post we provide an alternative to such closed systems. We utilise the shares broadcast on braidpool’s P2P network to enable miners to prove they generated those shares. We describe how single use seals can be used to trade these shares in an open market.
Delivering Shares To Market Makers
We present a protocol to deliver miners shares from braidpool, a decentralised mining pool. The shares are delivered with proof of ownership and once delivered to a buyer they can not be delivered to a different buyer, i.e. we prevent double spends. The buyer can further sell the shares following the same protocol it uses to buy the shares.
For the sake of this document, we assume we have a DAG of shares generated by miners and publicly visible on a peer to peer network. We also assume there is an accepted rewards distribution algorithm based on the DAG of share. See BraidPool Proposal for the current status on the proposal for these.
Trading Shares Using Bitcoin
We argue that trading shares doesn’t require a new blockchain and we can instead use existing well understood techniques to enable trading of these shares. Building a new blockchain poses substantial engineering challenges that we seek to avoid.
To transfer shares from miner to a market maker we use a PayJoin transaction. This enables atomic delivery of shares by miners.
Share Delivery By Miner
A miner can make a ‘delivery’ of shares to a market maker when exercising a futures contract. To do so, the miner has to prove the following to the market maker:
- Ownership - the miner selling the shares is the one that mined those shares, and
- No Double Spend - the shares being delivered have not already been delivered to anyone else.
We describe the delivery protocol in the next sections and show how the protocol provides these properties. First we describe the structure of a share.
A share’s header contains all the details required to build a DAG but for the purposes of the protocol presented here we focus on the components that help with the delivery of shares. A share header includes a ‘Share Seal’ that prevents a miner from double spending the share coin.
|Hash||Hash of the block found as share.|
|Nonce||The nonce found as the share.|
|Timestamp||UNIX timestamp for the block found.|
|Share Seal||A bitcoin UTXO.|
Before a miner broadcasts a share to the decentralise mining network, it can optionally add a ‘Share Seal’ to the share’s header. This Share Seal is a bitcoin UTXO that the miner has to spend as a part of the protocol to deliver the share to a buyer. We call this a Seal, since that is terminology used in Single Use Seals.
Once a Share Seal in a Share Header has been spent in a bitcoin transaction, the shares are “sold” and no other bitcoin transaction can spend these again.
The figure above shows how we can determine that shares have been sold or not. The shares 1, 2 and 3 are sold as their Share Seal has been spent and is no longer in the bitcoin UTXO set.
When a share is found by a miner, the share is broadcast to the p2p network so that the share can be included in the DAG of shares.
Recall that making sure that other miners in the DAG have your share is how miners can make sure they get rewarded for the share when the next block is found. See BraidPool Proposal for details.
The miner and the buyer execute a PayJoin to atomically execute a trade where the miner transfers sends shares to the market maker and the market maker in turn sends bitcoin to the miner.
The protocol can be described as consisting of three phases:
- Before Mining,
- During Mining, and
Before a miner starts mining shares it generates a UTXO and makes sure this UTXO is not spent up to the time of selling shares to a market maker. A miner can deliver as many shares as they want with a single UTXO as long as they included the UTXO as the ‘Share Seal’ in the Share Header. These shares and seals can be delivered in any combination.
When mining a share, the miner sets the ‘Share Seal’ in the Share Header to the UTXO generated in the previous step. At this stage the miners can decide on the granularity of the shares in each seal. Miners are free to choose a seal for each hours worth of shares or a weeks worth of shares. The trade off is the ability to delivery smaller set of shares, but at a higher number of bitcoin transactions.
To deliver shares the miner spends the UTXO from the ‘before mining’ stage in such a way that the market maker can verify that the shares have not already been delivered to anyone else. The market maker can also validate that the shares were generated by the miner.
When a market maker sees the Share Seal UTXO_1 spent on the bitcoin blockchain it knows that shares using UTXO_1 as a Share Seal can no longer be delivered to any other market marker.
The figure below shows how a miner includes ‘UTXO 1’ as a Share Seal in Shares 1 to 8, and therefore is selling those shares as part of the bitcoin transaction.
The Miner also proves the ownership of shares as the miner that used UTXO_1 as a Share Seal is able to spend UTXO_1.
Atomic Delivery of Shares
The above delivery protocol doesn’t guarantee atomicity. A buyer can receive shares from a miner and refuse to deliver the payment for the shares.
We make use of a PayJoin transaction to make this trade atomic. The following sequence of steps show how the miner can trade shares for bitcoin using a PayJoin transaction.
- Miner and Market Maker agree on the amounts of shares and bitcoin to exchange. The Miner sends the Share Headers it will be selling to the Market Maker.
- Miner and Market Maker then exchange the bitcoin addresses where they want to receive their payment.
- The Miner creates a bitcoin transaction spending the Share Seal UTXO and two outputs. One of these outputs pays the agreed upon bitcoin to the Miner and the other includes Buyers Seal in the op_return field.
- The Miner signs the transaction by signing the inputs and the two outputs.
- The Miner sends the signed transaction to the Market Maker.
- The Market Maker verifies that the number of shares being agreed upon include the UTXO being spent by the Miner.
- Once the Market Maker has verified the shares and the Share Seal, it adds an input and signs the inputs and outputs of the transaction.
- The Market Maker then sends the transaction back to the Miner.
- The Miner finally signs the updated inputs again and broadcasts the fully signed transaction.
The above sequence works to build a PayJoin transaction with the only extra details in Step 3, where the Miner must spend the Share Seal and must include the Buyer’s Seal in the op_return of the output sent to the Buyer.
The figure above shows a PayJoin transaction delivering Miner’s share with three different Share Seals.
We now show how the PayJoin above satisfies the ownership and no double spend properties.
Ownership: When the Miner spends the Share Seal during the PayJoin transaction the Miner inconclusively proves it controls those shares. A miner can try to construct a PayJoin transaction with another Miner’s Share Seal, but the requirement that the Miner spend the UTXO included in the Shares headers is verified by the Market Maker before it signs the transaction in Step 5.
No double spend: The spending of the Share Seal marks the shares as spent. When a buyer receives the list of shares in Step 1, it can verify from the DAG of shares that they are valid. It can also check that the Share Seal UTXO hasn’t already been spent.
The Miner can construct concurrent PayJoin transactions with multiple Market Makers, but only one of the transactions will be accepted on the Bitcoin network.
Trading Shares: An Open Market
If we want to support the ability for buyers to sell shares to other parties, we can support that by extending the Seal analogy. Once the Market Maker has ownership of shares by virtue of the data in the op_return of the PayJoin output, we can extend the protocol to recognise this ownership and then transfer ownership to a secondary buyer in a new PayJoin transaction.
The RGB protocol builds on Seals to provide off chain assets and we could use RGB to build the decentralised mining pool’s shares delivery mechanism. However, RGB is not yet ready for production use and we continue to work on our own simpler use case described herein.
There is a question on how the system might scale if each miner has to broadcast a bitcoin transaction to deliver shares. There’s two responses to it:
- A miner can use the same Share Seal for a day’s or a week’s worth of shares and deliver them in a single bitcoin transaction to the buyer.
- A miner could create a PayJoin with multiple inputs that spend different Share Seals to bulk sell shares.
We can switch away from using op_return and instead use the “sign-to-contract” commitments to transfer ownership of seals from Miner to Market Maker. These types of commitments are also used by RGB to record transfer of asset ownerships. However, we can use op_return an MVP of BraidPool and then switch to more advanced commitment systems as users demands.
In this document we outlined a protocol for Miners to deliver shares to a Market Maker. The protocol builds on the idea of Single Use Seals and doesn’t require a new blockchain to manage and track shares. We believe that enabling an economy of shares right on top of the Bitcoin blockchain reinforces the utility of Bitcoin, while providing a much needed tool for miners and market makers alike.
This post was first published as a gist.