Posts
-
Radpool and Fedipool
There have been a few discussions around Fedipool in the past. I explain how Radpool design is different from Fedipool. I also point out to how the Radpool network 1) can scale for providing payout variance reduction, and 2) provide a payout mechanism that provides unilateral exits.
-
Validating Shares is Not a Challenge
Evaluate the CPU required to validate all shares received at MSPs.
-
Custody of Miner's Coins in Radpool
I published a new design https://radpool.xyz, for a decentralised mining pool where the miners are paid out using DLC contracts between Miner Service Providers (MSPs) and miners. The DLC contract attestations are published by a federation of MSPs using a FROST threshold signature.
-
Async Rust (Part 3?)
We are now using the Service trait from Tokio via the tower crate for writing async code in FROST Federation. I have slowly gotten around to this taking my time writing async code using futures, then actor model and now the Service trait.
-
FROST KeyGen For Frost Federation With Broadcast
In this post we explain why we plan to use the implementation of FROST KeyGen from ZF FROST crate and how we by pass a well understood requirement for an agreement protocol in the second round of KeyGen.
-
FROST Threshold Signatures for Multiple Channel Updates
Chris Belcher proposed a hub based payout solution for P2Pool that won’t consume blockspace linearly with number of miners in a pool. The drawback of the approach was the requirement for a centralised hub. Belcher showed how that can be overcome using multiple hubs that each manage a fraction of the payouts. With Schnorr Signature now available in Bitcoin and advances in Threshold Signatures theory and practice, I show in this post how the hub based model will work with FROST Threshold Signatures.
-
Frost Federation
We need a threshold signature to manage the payout on a decentralised mining pool. FROST and ROAST are threshold signature schemes with the smallest network communication overhead with proven security guarantees. However, FROST places some requirements on the communication channels between peers. The FROST federation provides a Rust implementation for nodes that talk to each other over point to point communication and provide the network guarantees required by FROST.
-
DSL Taproot Coinbase & Optimised Docker Image
We are using the Bitcoin DSL to capture the workings for Braidpool’s payout mechanism. For this I had to wrap up a couple of loose ends in the DSL. I also optimised the Docker notebook image, so it is close to 1GB than to 4GB.
-
BFT Agreement and Threshold Signatures
Two distributed system protocols need to come and work together for Braidpool to work. These are a 1) BFT consensus protocol and 2) threshold signatures. In this post, I describe what each of these provide and requirements from a network model for each of them.
-
FROST Library for Point to Point Networks
This post outlines the communication requirements for implementing FROST in a point to point communication model, and describe my plans to build a Rust library providing FROST in a such network model. The library will be used to build a decentralised mining solution for bitcoin.
-
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