Braidpool is a peer to peer bitcoin mining pool that aims to:

  1. Low variance for independent miners, even when large miners join the pool.
  2. Miners can build their own blocks.
  3. Payouts in a constant size blockspace.
  4. Provide tools for enabling a hashrate futures market.

TLA+ Specifications

We are using TLA+ to specify and detect any potential errors early. The current list of protocols we have specified are:

  1. P2P Broadcast
  2. Shamir Secret Sharing
  3. 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.
  4. The above spec for block generation uses the Bitcoin Transactions spec. The transaction spec uses a simple scriptSig = scriptPubkey check.


  • GhostDAG Assumes a Synchronous Network Model

    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.

  • DKG+TSS is the Only Consensus We Need

    Braidpool without transactions, does not need a consensus from the DAG layer.

  • Providing Rounds for DKG/TSS Protocols

    We propose a solution to use proof of work to signal rounds needed for implementing DKG/TSS protocols.

  • Braidpool Context and Components

    Braidpool node architecture

  • FROST for Braidpool

    FROST [1] 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.

  • P2P Connection Lower Bounds

    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.

  • Generating Pool Key And Blocks to Mine

    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 getblocktemplate API call.

  • Synchrony in Bitcoin

    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.

  • Need for Specifications

    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.

  • Futures Contract Overview

    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.

  • Braidpool: Technical Summary

    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.

  • Delivering Hashrate to Market Makers

    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.

  • Can Braidpool Reuse P2Pool Components?

    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.

  • Why Braidpool?

    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