Our mission is to give you complete control of your Bitcoin mining operation — from the firmware on your machines to the transactions in the blocks you mine.
Data transfers can be encrypted to ensure their integrity and confidentiality. This hardens the protocol against man-in-the-middle attack vectors, namely hashrate hijacking in which an attacker intercepts a miner’s shares and submits them as their own in order to steal the payouts.
V2 has a fully binary format and eliminates unnecessary data transfers. This saves “a bit” of network bandwidth (about 2-3x times in comparison with Stratum V1) and decreases latencies.
Besides lowering infrastructure costs, Improved efficiency reduces hashrate variance by allowing higher submission rates, resulting in fewer stale share submissions.
Whether you operate a huge mining farm or just a couple of ASICs in your garage, Stratum V2 will make your life easier. Features like simplified header-only mining, zero-time backend switching, and many more allow for all sorts of unique setups
At the same time, Stratum V2 is designed to be easily extensible so that it can evolve to meet the needs of the mining industry for years and maybe even decades to come.
We were inspired by the BetterHash proposal to give users the option of freely selecting their own transaction set. By providing a custom job selection mechanism, we’ve integrated the idea into Stratum V2.
At the same time, the protocol gives mining pools the ability to reject externally negotiated mining jobs that are invalid, all while ensuring that mining rewards will be fair and that security is not sacrificed.
Proposing a new protocol for pooled mining is one thing, but actually pushing widespread adoption of it throughout the Bitcoin mining industry is something else. Braiins OS & Braiins OS+ We are making it easy for miners to upgrade to Stratum V2 by including a V2 implementation natively in the autotuning firmware, Braiins OS+.
“More comprehensive than BetterHash, individual job selection, zero time backend switching. If this protocol does everything it promises, "mining centralization" as an argument will be completely dead.”
“Huge congrats to @braiins_systems @TheBlueMatt @mor_pav @janbraiins for the Stratum V2 release! Brilliant & powerful work! This greatly decentralizes mining and remains committed to their mission of free open-source software in the #btc mining industry”
“Stratum V2 has a built-in mechanism for “multiplexing.” This means that hashers can have independent communication channels on the same connection, allowing their machines to share data about temperatures, voltages of chips or how their PSU behaves.”
“@slush_pool has launched specs for Stratum V2, a mining pool protocol that would help diminish the power mining pools currently hold. This will make Bitcoin more robust and unstoppable. Number go up.”
We are always open to insights and contributions from others in the mining industry.
If you want to contribute to the BTC mining stack upgrade or help spread adoption, we want to hear from you.
This is immense for mining centralization. Instead of focusing on the centralization of pools, we can now focus on centralization of actual miners/farm owners. You can see how this can change hash rate distribution in the chart below from Matt Corallo’s presentation about consensus group centralization. As for performance, it’s complicated. With a properly-optimized client and reasonably good internet connection, it can be faster than receiving work from the pool. But pools have to put a lot of work into properly optimizing their setups to make this possible.
Pools currently act as very large miners controlling a significant part of the total hash rate. This means that pools can try to prevent (i.e. censor) some transactions from getting into the blockchain or they can strongly influence the BIP activation process, as we saw with SegWit signalling in 2017. Miners who negotiate their own blocks can prevent this power centralization in pools, similarly to if they were solo mining. At the same time, miners can continue to benefit from decreased variance in payouts by mining with a pool.
In V2, pools can always actively reject a whole block proposed by a miner, but they can’t reject individual transactions within a block. I.e. pools do full block validation and reject any blocks that contain invalid transactions.
Authentication is really important. Without it, an adversary can try a man-in-the-middle attack (MITM) to quite simply steal money by redirecting hashing power to another pool. Public key signature authentication isn’t ideal because it’s quite slow, so verifying a signature for every message would be very inefficient.
Modern authentication encryption schemes provide exactly what’s needed: an authenticated channel between two parties where one relatively expensive signature operation is used to create a shared secret, which can then be used by much faster symmetric key authentication schemes. Modern implementations are really fast, well researched, and unlikely to run into engineering surprises.
In V1, an attacker can steal and modify job assignments before they reach miners, then intercept the work when the miner tries to submit it — all without the pool or miner being able to know it’s happening! V2 prevents this kind of attack, called “hashrate hijacking.”
The pool-to-miner overhead is about 5%, rather insignificant. For miner-to-pool communication it adds 16 bytes (more than 50%), but it’s important to put in context. Even with encryption, share submission messages in V2 are more than 50% lighter than V1. Furthermore, the total amount of transfers is reduced such that ultimately we’re not actually talking about much additional data due to encryption.
One of the biggest incentives for miners is the bandwidth efficiency improvements, which now makes it possible to operate even without really great internet connections. At the same time, this can improve submission rates which in turn reduces the variance in a miner’s hashrate (and thus their rewards in score-based reward systems such as PPLNS). Also on the efficiency front, the ability for pools to distribute future block templates to miners ahead of time (separately from the ‘SetNewPrevHash’ message) should eliminate empty block mining. Finally, the switch from JSON-based (i.e. human readable) code to a fully binary (i.e. machine readable) codebase significantly reduces the size of data transfers.
Another incentive that can’t be understated is cryptographic authentication. If you’re mining today, it’s entirely possible that your ISP is silently stealing 1% of your hashpower.
Encryption in V2 solves this.
There is a baseline for a reference implementation in the Braiins open-source repository which is currently being updated to reflect the latest version of the specification. We estimate that it will take at least 3-5 months to address any possible issues before it’s ready for deployment at scale. As for the implementation, it’s fairly straightforward. Farms can use a V1 to V2 translation proxy on sight and pools may also use V2 to V1 proxies as their first level of adoption before implementing the support directly into stratum.
The reference implementation is part of BOSminer, our replacement for the outdated CGMiner.
Braiins OS+ is an enterprise variant of Braiins OS that includes proprietary algorithms to perform per-chip autotuning on ASICs. Autotuning is a way to optimize the efficiency of a mining device (i.e. boosting the TH/W output) by calibrating the frequencies and voltages on individual hashing chips such that the chips with the highest quality silicon perform more work than lower quality chips.
Bitcoin ASIC manufacturers have increasingly kept their firmware closed-source, even making it difficult for their customers to change to another firmware if they want to. Considering how few manufacturers there are, we saw this as a centralized point of failure. By providing open-source firmware for ASICs, we help mitigate the risk of attacks by giving miners the ability to control their own hardware instead of being forced to trust HW manufacturers.
BOSminer is a replacement for CGMiner. The reason that CGMiner needs to be replaced is that — although it was an open-source project — hardware manufacturers have been developing their own CGMiner codebases behind closed doors. They often don’t commit their code to the open codebase until months or years after they start using it, by which time it’s no longer relevant. This makes it more complex to support new generations of ASICs with 3rd party firmware, as the firmware must adapt to different (and closed-source) versions of CGMiner on each machine. By building BOSminer and maintaining its open-source codebase, it will significantly reduce the complexity of firmware development for new ASIC machines.
You can read all about our reasons for building with Rust here.