Why decentralisation?

Bitcoin's long block time (10 minutes) introduces revenue variance for miners that can only be overcome by being a larger and larger miner. For this reason Mining Pools have come into existence to pool hashrate from different miners to reduce their variance. This directly impacts the decentralization of the bitcoin network since pools want to maximize their hashrate to minimize their variance, but cannot get bigger than 51% or they are perceived as an attack risk on Bitcoin. A centralized pool "looks like" an individual miner with respect to the Bitcoin network.

Braidpool aims to decouple the problems of transaction selection, variance reduction, device monitoring, and mining payout in order to enhance the businesses of both pools and individual miners.

What does Braidpool mean for miners?

Miners can continue to use the pools they have existing relationships with (assuming their pool runs on Braidpool) for the reasons above. They will have to run the Braidpool node software and a Bitcoin full node. Braidpool will provide Docker images to make this as easy as possible since we know this is somewhat of a hurdle, but we believe this technical hurdle is easier to solve than the variance reduction and tx selection problems existing pools have.

Miners can choose to run on top of Braidpool directly. The payout algorithm is Full Proportional meaning over a single difficulty adjustment window (2016 blocks -- about 2 weeks), all funds (both block rewards and all fees) mined by Braidpool are paid out to miners in proportion to the shares they submitted to the pool. The choice of paying over an entire difficulty adjustment window is intended to avoid arbitrary "smoothing" that happens in PPLNS pools, while providing a definitive hashprice for each difficulty epoch that can be traded to create risk-management tools (financial derivatives). It is also chosen so that rewards are aggregated over a sufficient time period so that Braidpool does not create huge coinbase transactions like Eligus, Ocean and P2Pool, which competes with fee revenue. For instance one could buy shares in one epoch and sell shares in the upcoming epoch through private agreement, in order to create a hashrate derivative instrument.

How does a Braid actually look like ?

The above braid is a data structure consisting of beads represented as nodes of the braid also termed as weakshare

Bead/Weak-share

Braidpool Committed Metadata

Braidpool UnCommitted Metadata

How is consensus achieved in braidpool ?

The consensus algorithm we choose is inspired by simply extending Nakamoto consensus to a Directed Acyclic Graph. We call nodes in this DAG "beads" and the overall structure a "braid" so as to distinguish it from the bitcoin blocks and chain. Some of the beads in the DAG are bitcoin blocks.

We call this structure a "braid" because it contains an extra restriction relative to a general DAG: beads must not name as parents other beads which are ancestors of another parent. Naming a parent that is an ancestor of another parent conveys no useful information, since ancestors of each parent are already implied when ordering the DAG and including transactions. Visually this means that a braid will never have triangles or some other higher order structures.

A DAG can be totally ordered in linear time using either Kahn's algorithm or a modified depth-first search which terminates when a bead is found that is a common ancestor to all of a bead's parents, which defines a "graph cut" and a point of global consensus on all ancestors. We define the set of beads between two graph cuts to be a "cohort". Within a cohort it is not possible to total order the contained beads using graph structure alone. The cohort can be defined as a set of beads having the same set of oldest common descendants and youngest common ancestors.

We have considered the PHANTOM proposal which has many similarities to ours and should be read by implementors. We reject it for the following reasons:

• The k-width heuristic is somewhat analogous to our cohorts, but has the property that it improperly penalizes naturally occurring beads. If for example we target the bead rate such that 40% of the cohorts have 2 or more beads, this means that approximately 2.5% of cohorts would have 4 or more beads. The red/blue algorithm of PHANTOM would improperly penalize all but the first three of the beads in this cohort.
• It is impossible in practice to reliably identify "honest" and "attacking" nodes. There is only latency, which we can measure and take account of. Even in the absence of attackers, cohorts exceeding the k-width happen naturally and cannot be prevented.

What had braidpool proposed in SoB?

As part of my Summer of Bitcoin journey, I’m contributing to Braidpool—a decentralized, cooperative mining pool—by implementing a crucial component called the Committed Mempool. Unlike traditional mining pools that centralize transaction selection and block proposal, Braidpool aims to stay true to Bitcoin’s ethos by decentralizing as much of the mining workflow as possible. My contribution bridges the gap between share-level transaction commitment and distributed consensus among pool peers.

In Bitcoin, the mempool is a volatile memory pool that holds all valid but unconfirmed transactions. The idea of a Committed Mempool in Braidpool is to introduce a second, more deterministic mempool within each participating bitcoind instance. This mempool will hold only those transactions that have been explicitly committed inside Braidpool shares (called "beads"). Each bead—a proof-of-work share submitted by miners—can commit up to ~5 transactions.

When a miner node (called a braid-node) constructs a share, it includes a few selected transactions. These are broadcast to other peers via a Floodsub-like pub-sub P2P protocol, and each peer processes these transactions and places them in their own committed mempool. This enables deterministic block construction from a pool of pre-committed transactions across the entire Braidpool network.

To enable decentralized coordination, we’re using libp2p for peer-to-peer communication among braid-nodes. My work involves implementing and refining: Topic-based gossip using Floodsub or Gossipsub (evaluated for reliability). Peer discovery and connection establishment using QUIC for transport, Yamux for multiplexing, and Noise for encrypted handshakes. Bead announcements and transaction sync via custom protobuf-encoded messages. Each node in the network can subscribe to topics like bead_announce, tx_commit, or peer_discovery to propagate relevant events.

To allow local clients (wallets, dashboards, or debug tools) to communicate with their braid-node, I’ve implemented an RPC server using an HTTP+JSON interface. This enables: Querying the committed mempool. Submitting transactions for inclusion in future shares. Monitoring active peers, received shares, and network health.

My proposed architecture

• Since the current Braidpool implementation was based out of zmq, It required a change utilizing the IPC instead for lower latency fecthing of block-template via `getblocktemplate`. So i had proposed the utilization of Cap`n`Proto being followed in Bitcoin-Core along with `libmultiprocess` for the integration of IPC functionality into the core .
• I had been following the bitcoin-core PRs for some-time so i was able to find out what can be the standard that core follows that can also be aligned to Braidpool requirement as well .
• Proposing `libp2p` for the network stack binded to Braid-node was due to the efficient functionality for a robuse `transport` along with encyption and opting for `Floodsub` protocol instead .
• SV2(Stratum-V2) proposal was mainly to utilize the sub-protocol of `binary-framing` for the idea of overhead message encyption for the improvement on the parts of security and lower latency and `mining_protocol` for the `nonce` distrubution across the lower nodes apt for scalability of pool functionality.

I will further keep you updated on my progress in my subsequent blogs. Stay Tuned!!