Explaining how Job Negotiation works in Stratum V2 and how it improves decentralization of Bitcoin mining.
With the recent news that Square Crypto is looking to support Stratum V2 development with a grant, we thought it was time that we explain more about how Job Negotiation works and the benefits it provides.
We’ll start with a technical explanation of the pooled mining process with both Stratum V1 and V2, as this hasn’t been explicitly explained in the documentation on stratumprotocol.org and it’s really important if we are to understand the actual improvements V2 makes. Then we’ll address two of the most common concerns we’ve heard from miners about the practicality of enabling miners to choose their own work in Stratum V2. From there, we will walk through one of the biggest theoretical attacks many Bitcoiners worry about, the “state attack.” And finally, we’ll describe how it all fits into the modern mining industry from a short-term and long-term business perspective.
First, let’s go through the order of operations so that everybody is on the same page.
If you aren’t already familiar with how mining pools operate, we recommend you read the relevant sections of Mastering Bitcoin.
Presently, this is a summary of how work is typically done in pooled mining:
Pools and solo miners are the only entities that are constructing block templates. Regular miners cannot because they don’t have the transaction sets to build the blocks.
This is a simplified overview of how pooled mining will work in the future for miners who choose to construct their own blocks:
Since block propagation does not necessarily depend on the pool node, it occurs as rapidly as it would if the miner were simply solo mining.
An important question that arises is how payouts will be handled when miners can be working on different blocks while part of the same mining pool. The answer is that every miner is paid based on the value of the shares they submit, not based on the value of the block that gets mined.
For instance, suppose there are two block templates being worked on by the miners of a single pool:
Miners working on the 8.0 BTC block will be paid proportionally more for their valid shares than those working on the 7.5 BTC block. This means that miners with well-connected full nodes may be able to work on blocks that are more valuable than those distributed by the pools themselves, thereby increasing their payouts relative to the miners who aren’t proposing their own block templates. More importantly, it means that miners who propose blocks with lower value transaction sets will receive proportionally lower payouts, but they won’t impact the payouts of the miners in the rest of the pool.
Another point worth discussing is what happens in the moments immediately after a new block is found and propagated. The Job Negotiation process can take several seconds, and every second counts when searching for nonces. This gray area can be addressed with an asynchronous start, which means that miners can begin working on their own blocks immediately while the pool is still validating them. Once the pool validates a proposed block template, the work already done by the miner(s) is paid for accordingly. In the event that a miner proposed an invalid block template, the shares from those few seconds of work are rejected and don’t earn payouts.
A proposed block template can be rejected for two reasons:
Critically, the miner is tipped off that they should reconnect to a different pool or solo mine if an error is received but the block they proposed was valid. Thus, Job Negotiation does not give miners the ability to work on any random block template they want, but it serves as an early warning system that alerts miners to possible issues with pool operators much earlier than if the miner was not running a full node and proposing their own work.
With this overview of how Job Negotiation works, we can now think about how it might actually come into play in the real world.
Let’s suppose that 4 pools with a combined majority of the total network hashrate are all simultaneously commandeered by a malicious party (e.g. their nation’s government). Despite the pool operators not wanting to tarnish their reputations or damage the network they have a large stake in, the malicious party gives them no other choice but to participate in a 51% attack and deep reorg.
In the Stratum V1-only scenario, the miners supplying the actual hashrate to those pools might not realize that they are unwillingly participating in an attack until it’s too late.
For a hypothetical future scenario in which some of those miners are choosing their own work, they would know that something is off as soon as their valid block templates were rejected. If miners controlling a large enough portion of the hashrate for those 4 pools were proposing their own work, they could effectively prevent a sustained 51% attack by switching pools as soon as their original pools start censoring them. It doesn’t mean that all miners in those pools need to be proposing their own blocks — just a large enough percentage to bring the cumulative hashrate of the attacking pools below 50% if those miners running full nodes switch.
A quantity of 4 pools is used for this example because that is the minimum it would take with today’s hashrate distribution, but it could just as well work with 1 pool having a majority of the hashrate in the future. It’s important that some pools remain honest and uncompromised in this scenario, as solo mining isn’t economically viable for the majority of miners.
Since pools are temporary custodians of mining payouts, one can argue that pools could simply not send BTC to a miner who, for example, includes a transaction in their block that the pool didn’t want included. In other words, the pool can still censor their miners by attaching conditions to payouts, thus defeating the purpose of decentralized work selection.
For this argument, there are two key points to consider:
As with many aspects of the Bitcoin ecosystem, there is a tradeoff between user experience and security. Large mining pools with thousands of users are not completely trustless, but offering frequent payouts and having adequate skin in the game minimizes risk, as does the easiness of switching pools at any time should trust be damaged.
Although we know how Stratum V2 Job Negotiation can be implemented practically, there's still a valid question as to whether or not today’s miners care about building their own block templates.
Stratum V2 improving Bitcoin’s decentralization depends on Job Negotiation reaching significant adoption, and that may not happen. We can imagine some use cases emerging for Job Negotiation which incentivize its adoption, including the one we described above in which miners having well-connected nodes are able to increase their revenue by working on higher value blocks.
Ultimately, we believe that this is a natural part of the evolution of the mining industry. Large scale miners are investing millions of dollars into building and maintaining efficient operations, and it takes a lot of time to break even on those investments. By running their own full nodes and working on their own block templates, miners can add redundancy (safety) to the network and strengthen Bitcoin’s fundamentals at minimal added cost. That is in the self-interest of every miner wanting to protect and maximize their long-term ROI.
Decoupling block building and propagation from pool reward payouts is not a perfect solution, but it does provide an early detection system for malicious behavior by pool operators. It also adds more mining full nodes to the network and even incentivizes them to be well connected so that they can mine more valuable blocks with higher cumulative transaction fees.
Adoption will not happen overnight, and in fact it may take many years. Nonetheless, we as pool operators are committed to building a full implementation of Stratum V2, offering Job Negotiation to our miners, and educating the community about this important and often misunderstood sector of the Bitcoin ecosystem. We hope that other pool operators will join us in this worthwhile initiative.
Operators of Slush Pool. Creators of Braiins OS+ autotuning firmware & a fully open-source mining stack: Braiins OS + BOSminer + Stratum V2.
Industry leaders in transparency and innovation, with more than 1.25 million BTC mined since 2010.
Increase hashrate on S9s to 17+ TH/s, improve efficiency as much as 20%, and get 50% lower pool fees on Slush Pool
Cutting-edge firmware with an implementation of Stratum V2 and mining software written from scratch in Rust language.
Quality improvements including reduced data loads, empty block elimination, hashrate hijacking prevention, and more.