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.

Why it’s called Job “Negotiation”

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.

Stratum V1

Presently, this is a summary of how work is typically done in pooled mining:

1. Miner connects to pool
2. Pool sends miner job assignments (i.e. block templates to work on, without full transaction sets)
3. Miner does work (i.e. plugs in nonce values looking for hashes below the difficulty target)
4. Miner sends proof of work (i.e. nonces leading to “good enough” hashes) back to pool
5. Pool validates the proof and broadcasts blocks when found
6. Miner gets paid for their submitted proof of work (so called "shares")

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.

Stratum V2

This is a simplified overview of how pooled mining will work in the future for miners who choose to construct their own blocks:

1. Miner connects to pool
2. Job Negotiator (i.e. software run by the miner or 3rd party between miner and pool) sends request to the upstream pool node to work on a block template
3. Pool verifies that the transactions included are valid*
4. Pool verifies coinbase transaction outputs are correct (i.e. paid to the pool address)
5. Pool accepts the proposed block template**
6. Miner works on their own block template
7. If a block is found, the miner can propagate the block themselves and censorship by the pool is not possible
8. Miner gets paid for their submitted shares

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.

*Economics of Job Negotiation

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:

• Block Template 1 value: 8.0 BTC
• Block Template 2 value: 7.5 BTC

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.

**Latency concerns

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:

1. It is invalid 
2. Censorship

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.

Example of Job Negotiation in action

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.

What about payouts?

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:

• The pool either rejects or accepts block templates at the beginning of mining rounds, and the miner can propagate found blocks themselves.
• Pools send payouts frequently (multiple times per day in most cases), so the financial risk for miners of not getting paid for valid work is minimal. Meanwhile, pools who don’t pay their miners risk permanent reputational damage and loss of future business.

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.

Decentralization for decentralization’s sake

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.

Conclusion

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.

Further Reading

For more information about mining pool exploits addressed by Stratum V2, we strongly recommend this article from StopandDecrypt written about Job Negotiation's predecessor, BetterHash.