Introduction
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.
TLA+ Specifications
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.
Posts
-
Lighting Contracts using Bitcoin DSL
I spent the last couple of weeks working on the details of Bitcoin DSL and working on a jupyter notebook that can be started from a docker image. The docker jupyter notebook will make it easy for others - and my future self - to use the DSL.
-
Bitcoin DSL
I find the usual way of crafting transactions and then using CLI to send them to bitcoin node and then query the node etc a bit tedious. I have long wanted a high level DSL to achieve this. So I spent some time building a DSL for creating transactions and interacting with a bitcoin node.
-
Connection management, broadcasts and more Rust
Last week I focused on setting up components for managing connections and adding support for broadcasting messages to all connected nodes. I also revised the configuration parsing component to handle defaults cleanly with less redundant code.
-
Weekly Development Update - Fearless Concurrency
The main focus this week was to pick up the tricks of trade in Rust for concurrent programming. I also put some effort in bumping up the test coverage to 90%. I am also tracking development as a github project with a roadmap.
-
Weekly Development Update - Async Rust
I plan to post a weekly development update on this blog. I will use the category
development-updatesfor these. -
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
-
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 isN. 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
getblocktemplateAPI 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