Decentralized Mining with Braidpool

Hey, I’m a final-year post-grad student majoring in Computer Application, and this summer I participated in the Summer of Bitcoin program. My project was Braidpool, a mining pool aimed at facilitating decentralization in Bitcoin mining. In this project, I worked with my mentor, Bob McElrath, who is the founder and maintainer of the Braidpool software.

What’s Braidpool and Why we need this?

First, I want to discuss the current situation in Bitcoin mining. Bitcoin mining hardware (ASICs) is expensive and uses a lot of power and infrastructure. This means only large companies or well-funded entities can operate them on a large scale, while small hobbyist miners have mostly been pushed out. As a result, mining power has concentrated in large industrial farms that can negotiate cheap electricity contracts, access renewable or stranded energy sources, and operate in regions with favorable regulations.

Second, even if many individuals own ASICs, they usually don't mine alone. The variation in finding blocks is so high that most miners join mining pools to make their rewards more consistent. Over time, a few pools like Foundry USA, Antpool, and F2Pool have grown to control most of the hashrate. This gives them too much influence over which transactions are included in blocks, raising concerns about censorship and centralization of block templates.

Third, geographic centralization is another risk. For example, before China's 2021 mining ban, more than half of Bitcoin's hashrate was concentrated there. After the ban, much of it moved to the U.S., Kazakhstan, and Russia, but the trend of clustering in areas with cheap power continues. This geographic clustering means that local government policies, like energy restrictions or bans, can greatly affect global mining.

The risks mentioned above pose a real threat to mining decentralization and the Bitcoin infrastructure and economy. The main goal of Braidpool is to minimize these risks by addressing them at the software level. Braidpool do this using factors like:

Eliminates Pool Operator Control
In today's pools, a single operator chooses the block template, deciding which transactions go into a block. This gives them significant power and creates a risk of censorship. With Braidpool, block construction is decentralized—miners work together using a consensus protocol to agree on transactions. This prevents any single party from controlling which transactions are mined.
Reduces Centralization of Hashrate
With Braidpool, miners can join without relying on a centralized server, preventing the hashrate from clustering under a few pool operators. Instead, the hashrate is spread across many peers, making the network more resilient to government pressure, shutdowns, or censorship. Technically, Braidpool uses beads as small proof-of-work blocks containing a few transactions (around 4-5) and a very low difficulty target compared to an actual Bitcoin block. All these beads are then appended to the Direct-Acyclic-Graph (DAG). When a miner requests a valid block template, all transactions are selected from this DAG in a decentralized way.
Censorship Resistance
In centralized pools, governments or regulators could force operators to exclude certain transactions. With Braidpool, there is no single operator to pressure—transaction selection is done collectively using beads. This enhances Bitcoin’s ability to resist censorship.

What I did?

My job is to create a Rust IPC client interface between Braidpool and Bitcoin. Interestingly, Braidpool is one of the first software applications to fully use IPC to communicate with Bitcoin instead of the traditional JSON-RPC/ZMQ. Here's a basic overview of the communication process: 1) The Bitcoin node starts with multiprocess functionality and specifies the location of the Unix Socket. 2) The Braidpool node also starts, pointing to the same Unix Socket and connects to it. 3) Then, using Cap’n Proto, a method is called from the client side (Braidpool), and serialization and deserialization of the information occur on both the client and server sides.

Apart from this is implemented all the necessary features that every mining pool should need:

Asynchronous API and Operation

Built on Tokio to handle many concurrent operations without blocking, when a public method like get_mining_tip_info is called, it creates a oneshot channel for the response. It packages the request parameters and the sender half of the channel into a BitcoinRequest enum and sends it to the processor. It then awaits the receiver half.
Priority Request Queuing

This is a crucial feature for a mining pool. Not all requests have the same level of importance. For example, if we find a block but delay processing and sending it to peers, and another pool finds a block and sends it before us, we will lose our block reward. Thats why we need priority request processing. For this I have defined Critical, High, Normal, and Low priorities in a Queue. The processor always pulls from the Critical queue first, then High, and so on. This ensures that a request for a new block template (High priority) is never stuck behind a less urgent request.
Dual-Connection Model

Two separate UnixStream connections are used for Bitcoin Core. One connection is for the Processor Task to manage general requests. The other is for the Tip Watcher Task to handle the long-polling call (block notification).
Metrics and Health Monitoring

The QueueMetrics struct uses AtomicUsize to safely track statistics from multiple threads without needing locks. It monitors queue sizes, total, processed, and failed requests, as well as a moving average of processing time. The is_healthy() method gives a quick snapshot of the system's health, which can be useful for external monitoring or making load balancing decisions.
Graceful Shutdown and Error Handling

The shutdown method sends signals to both background tasks, letting them complete their current work, disconnect smoothly, and then stop. If the client is just removed from scope without calling shutdown, it will instantly send shutdown signals and abort() the tasks. This helps avoid orphaned tasks and resource leaks.

Besides creating the IPC client, I have worked on generating a valid block template for the downstream miners. This involves fetching the raw block template using the IPC client, recalculating the merkle root using merkle paths, creating the new coinbase for Braidpool, and then serializing all the block data.

How’s my overall experience?

Well, I have to say, I've really enjoyed working on this project! It exceeded my expectations. When I first started this internship, I wondered if I could complete everything, but I'm happy to say I achieved all my tasks and goals. The support I received from Bob McElrath was truly amazing. He was always there to help whenever I ran out of ideas and encouraged us to share our thoughts. The best part is that he's very welcoming if you have a great idea. The fellow students I worked with were also great; we collaborated as a team on different aspects of the system. I think we can now say that we have significantly advanced the Braidpool ecosystem over the past few months, and the project is in great shape and ready to move forward for production use.

I definitely want to see Braidpool become a key player in the Bitcoin mining industry. Unlike other pools that focus on earning block rewards, Braidpool is here to promote decentralization, freedom, and sovereignty. All our code and consensus are open source and free to use.

What’s next?

The plan moving forward is to conduct extensive testing of Braidpool within the testnet and regtest environments. These environments will allow us to simulate real-world conditions without the risks associated with deploying directly to the mainnet. Our goal is to thoroughly evaluate the system's performance, stability, and security in these controlled settings. By doing so, we aim to identify and resolve any potential issues that could arise during actual use. If the tests are successful and meet our expectations, we are optimistic about releasing Braidpool for mainnet use by the end of this year. This timeline will enable us to ensure that Braidpool is robust and reliable, providing a seamless experience for all users when it goes live on the mainnet.

Thank you,

Mohd Zaid