Get in Touch
We apologize but this page has not yet been translated to your language.
MINING PROTOCOL

Stratum V1

Stratum V1 Mining Protocol

a
b
c

Key facts

  • Introduced in 2012 to solve some of the Bitcoin mining industry’s growing pains

  • Was an evolution of the getwork protocol

  • Helped Bitcoin mining pools to serve more users with higher hash rate

  • First implemented on Bitcoin.cz Mining Pool which is now called Slush Pool

In 2012, Marek "Slush" Palatinus introduced stratum protocol as an evolution of the getwork protocol for Bitcoin mining. Stratum V1 solved some of the growing pains that Bitcoin mining was experiencing when it first became popular.

Getwork Protocol Limitations

In the early days, Bitcoin mining required miners to connect and interact with the Bitcoin protocol itself by running full nodes. 

To standardize the communication between miners and Bitcoin protocol, an open-source “getwork” protocol was used as a quick and easy solution for standalone miners to start mining. The getwork protocol utilized HTTP as a method to connect with the Bitcoin protocol. However, HTTP is typically used for web pages, and it was not ideal for coordinating peers to mine Bitcoin. Thus, many inefficiencies became apparent as mining grew more popular. 

By 2012, getwork’s inefficiencies had grown very problematic as mining underwent radical changes and network hashrate grew exponentially. This required a considerable amount of network bandwidth on the miner side and a practically infeasible amount of bandwidth on the server (i.e. pool) side to facilitate the increase in miner participation. 

At this point, it was quite clear that the getwork protocol was not a scalable solution. 

Popularizing Pooled Mining 

Around late 2010, a serious shift occurred in mining as more and more people joined the network. With 10 minute block times but thousands of miners competing to find each block, many participants were no longer earning revenue reliably enough to keep mining. 

The solution was for miners to pool their computing resources together so they could find blocks more consistently and therefore receive a portion of the block reward regularly enough to have a decently stable cash flow. 

However, the limitations of the getwork protocol became even more apparent as pooled mining grew in popularity. This led Marek "Slush" Palatinus, who created Slush Pool in 2010, to develop the stratum protocol (Stratum V1) for communication between miners and mining pools. 

Main Improvements with Stratum V1

Stratum V1 has been the standard protocol used for pooled mining during the past 7-8 years, during which time Bitcoin’s total network hashrate has increased by from ~20 TH/s to 130 EH/s.

Needless to say, it’s been a wild success. Ultimately, the widespread adoption and long-term use of Stratum V1 is due to 2 major scalability improvements it enabled:

Long-Polling

For reference: https://slushpool.com/help/stratum-protocol/?c=btc 

With the getwork protocol, miners were constantly sending requests to Bitcoin daemon (bitcoind) for mining work. When pooled mining took off, it complicated matters because it was now the role of pool servers to send the work to miners. Miners faced a choice between short-polling intervals to minimize their stale ratio, or long-polling using a separate connection to the pool servers to minimize network load.

Long-polling was the better solution, but it created some issues with load balancing in pool backends. Stratum V1 was built in a way so that instead of miners essentially requesting information from bitcoind via their pool over HTTP, the pools would be able to drive the load and broadcast messages to miners at anytime with no HTTP overhead or long-polling workarounds. This was a big improvement both for miners and pool operators. 

Extranonce Rolling 

Prior to the introduction of extranonce rolling in Stratum V1, miners were only able to modify 2 fields in a block header (nonce and ntime) which they would then hash to search for a solution to a block. Once a miner ran out of new possible combinations, they would need to make a request for more work from the pool (or straight from bitcoind), which was rather inefficient. 

Stratum V1 introduced the extranonce field to expand the unique combinations that miners could iterate through when they were assigned some work. By moving this ability to create unique block headers to hash from the pool to the end miners, the whole pooled mining process was made much more efficient.

Other Benefits

Besides these significant improvements in the technology, another reason that Stratum V1 was ultimately such a success was that it sent JSON payloads which were human readable and already widely supported in Bitcoin mining clients. JSON came with some overhead (which we’ve reduced significantly by switching to binary in Stratum V2), but it suited the industry needs well at the time. 

Criticisms of Stratum V1 

Stratum V1 was criticized for being initially developed as a secret to the public as no formal BIP was used to describe its implementation. However, it was argued that Stratum V1 is not related to the Bitcoin protocol or implementation — rather it is a custom pooled mining extension which shouldn’t require an official BIP.

Another source of controversy was that, while Stratum V1 was being developed, the community had spent months developing an open-source protocol called “getblocktemplate’ (BIP22) that would supersede the “getwork” protocol. With Stratum V1 being released near the same time, direct adoption for the getblocktemplate protocol suffered. However, it should be noted that the Stratum servers use a getblocktemplate mechanism under the surface, while simply adding a lot of other improvements around it. 

Unfortunately, the one significant downside of not using the getblocktemplate solution was that miners lost the ability to construct their own block templates (i.e. choose which transactions are in the blocks they mine.) Although this doesn’t harm the economic incentives of mining at all because miners are all incentivized to include the highest fee transactions in their blocks, it does introduce a vulnerability if pool operator(s) were to be compromised. This is why we are reintroducing the ability for miners to construct their own blocks in Stratum V2.

Finally, there’s the matter of security. As Ruben Recabarren pointed out in his paper, Hardening Stratum, the Bitcoin Pool Mining Protocol, Stratum V1 is vulnerable to possible man-in-the-middle attacks. Although no significant cases of "hashrate hijacking" have been reported, it's possible that they can occur undetected, making it all the more critical that the Bitcoin mining industry moves on to a more secure protocol. Hashrate hijacking prevention is another key feature of Stratum V2.

Beyond Stratum V1

Ultimately, Stratum V1 has served its role magnificently as the pooled mining protocol used throughout the mining world. With that being said, there is room for improvement, and that’s why we (Jan Capek and Pavel Moravec) along with Matt Corallo have introduced Stratum V2.

“It solves historical technical and security issues, it is generally much more efficient and it allows some advanced use cases like work selection or easier mining farm management,” Braiins co-CEO Pavel Moravec told Bitcoin Magazine. “This should have been done years ago, really.”

However, much has changed since the original stratum protocol was published in 2012. A single ASIC mining machine today is capable of producing greater hashrate than the entire Bitcoin network had back then (approximately 20 TH/s). Stratum V2 is the solution for the continued evolution of the Bitcoin mining industry.

Explore STRATUM V2