Braidpool is a peer to peer bitcoin mining pool that aims to:
- Low variance for independent miners, even when large miners join the pool.
- Miners can build their own blocks.
- Payouts in a constant size blockspace.
- Provide tools for enabling a hashrate futures market.
We are using TLA+ to specify and detect any potential errors early. The current list of protocols we have specified are:
- P2P Broadcast
- Shamir Secret Sharing
- Miner share accounting and block generation We specify how broadcast shares are accounted for towards miner payouts. When a bitcoin block is found, all unaccounted for shares are added to miners Unspent Hasher Payout (UHPO). We do not spec out how the distributed key generation algorithm is run - instead we replace the public key for coinbase payout to simply be the concatenation of the miner id.
- The above spec for block generation uses the Bitcoin Transactions spec. The transaction spec uses a simple scriptSig = scriptPubkey check.
The GhostDAG protocol implemented by Kaspa network uses a partial synchrony network assumption. The maximum message delay is an input to a function that approximates the maximum width of the network. This maximum width is then used as a configuration option for a network instantiation. The authors claim that the message delay is not know a priori, however, this maximum width is.
Braidpool without transactions, does not need a consensus from the DAG layer.
We propose a solution to use proof of work to signal rounds needed for implementing DKG/TSS protocols.
FROST  is the most recent threshold signature scheme that sacrifices robustness for reducing communication complexity. We consider braidpool’s communication model and our requirements from a threshold signature scheme (TSS). We argue that we braidpool will benefit from FROST’s signing phase without a signature aggregator and that braidpool should use Pedersen’s DKG for robust distributed key generation (DKG). Both of these are suggestions from the FROST paper.
Apart from the standard requirements of a P2P node, braidpool will require that all nodes are connected to
log_10(N)peers when the network size is
N. The reason for this requirement is to provide fast message propagation across the network while paying the cost of higher resource requirement at each node.
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
Bitcoin requires nodes to be synchronised within two hours of each other. Does this mean bitcoin uses a partial synchronous communication model? The answer is no, because bitcoin does not assume bounds on message latency or on message processing times at each node.
We have started a discussion around writing down specifications for braidpool. This is motivated by the need to clarify the details in our own heads as we build braidpool, but also to enable contributions to braidpool.
In this post we describe a futures contracts between miners and market makers that is enforced by the bitcoin blockchain. Miner and market agree on a Exahash to BTC price on a fixed date (expiry date). On the expiry date, the miner and the market maker execute an atomic trade to exchange the hashrate (and any payouts earned) for BTC.
This post provides a technical summary of how Braidpool works. There are three main components to braidpool 1) a DAG of shares to track work done by miners and calculate rewards, 2) one-way payment channels for payments with fixed blockspace requirements and 3) Single Use Seals to trade miner shares on an open market. The detailed proposal can be found here.
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.
Just like P2Pool, Braidpool uses peer to peer communication between miners to track PoW shares. The question then is, can we extend P2Pool to achieve the goals of Braidpool? In this post we present how Braidpool is different from P2Pool and why Braidpool is not building on the P2Pool codebase.
Current mining pools can be forced into censoring transactions and their opaque accounting limits their use for building financial tools that can help miners manage their business risks. This post briefly discusses the limitations of centralised mining pools and provides motivation to build Braidpool.
subscribe via RSS