AsicBoost

Efficiency improvement for ASIC mining devices that lowers their electricity consumption.

Bitcoin Core

Free and open-source software that includes a full node implementation for Bitcoin.

bitcoind

A Bitcoin client / program that implements the Bitcoin protocol for remote procedure call (RPC) use.

Coinbase transaction

The single transaction in each new block sending the block reward of newly mined Bitcoins (i.e. a new UTXO) to the address of the miner.

Coinbase

Special field containing the input for the coinbase transaction as well as up to 100 bytes of data available for arbitrary use.

extraNonce

Since the nonce is a 32-bit number, the highest nonce possible is 232, or approx. 4 billion; the extraNonce is a field in the coinbase used to iterate the nonce and expand the search space.

Merkle root

The root hash of a Merkle tree which contains the coinbase transaction and the transaction set consisting of all the other transactions in the block.

Mining Device (i.e. Client)

Furthest downstream node; does the actual hash computations, i.e. the proof of work.

Nonce

Abbreviation for “number only used once”; In Bitcoin, the nonce is a 32-bit-long value which is adjusted incrementally and used to rehash a hashed block until the hash output meets the current difficulty level restrictions of the network, signaling a valid solution has been found and the miner can then propose their block to the rest of the network.

nTime rolling

nTime is the integer timestamp (in seconds) included in the block header. NTime rolling is a way for miners to increase the timestamp locally in their hardware rather than requiring a new block header from their pool every single second, reducing the amount of data transfers that need to occur between pools and miners. An explicit nTime rolling value instructs miners how long they can increment nTime (in seconds) before they need to request new work (i.e. a new, valid block header to mine on) from the pool.

Pool Service (i.e. Server)

Furthest upstream node, responsible for generating unique jobs for each connection to the server by putting unique data into the coinbase.

Proxy

Intermediate node, used for hashrate / difficulty aggregation.

Transaction set

All transactions being included in a proposed block.

Version rolling

Changing the block version value in the first field of the Bitcoin block header, thereby enabling AsicBoost.

Mining Protocol

The next generation protocol for pooled mining by Pavel Moravec and Jan Čapek, in collaboration with Matt Corallo and other industry experts.

a
b
c

Stratum V2 is the next generation protocol for pooled mining. It focuses on making data transfers more efficient, reducing physical infrastructure requirements for mining operations, and increasing security. Additionally, Stratum V2 introduces three new sub-protocols that allow miners to select their own transaction sets through a negotiation process with pools, improving decentralization.

In the sections below, we’ll go through Stratum V2 feature-by-feature so that you can understand what’s changed from V1, why those changes matter, and how it all works on a technical level.

Note: Before you dive into the technical details, be sure that you understand the Terminology we’ll be using.

Protocol Overview

Device

The actual mining machine computing the hashes.

Proxy

An intermediary between Mining Devices and Pool Services that aggregates connections for efficiency and may optionally provide additional functionality, such as monitoring the health and performance of devices.

Hashrate Consumer

An upstream node to which shares (i.e. completed jobs) are being submitted. The most common hashrate consumers are pools.

Job Negotiator

A node which negotiates with a pool on behalf of one or more miners to determine which jobs they will work on. This node also communicates with a block template provider (e.g. bitcoind) and sends jobs to mining proxies to be distributed to miners.

Mining Protocol

This is the direct successor of stratum protocol v1. It’s the main protocol used for mining and the only part of the full protocol stack that needs to be implemented in all scenarios. It is used for communication between Mining Devices, Proxies, and Pool Services.

The protocol defines three types of communication channels: 
  • Standard channels don’t manipulate the Merkle path / coinbase transaction, greatly simplifying the communication required between them and upstream nodes.

  • Extended channels are given extensive control over the search space so that they can implement advanced use cases (e.g. translation between v1 and v2, difficulty aggregation, custom search space splitting, etc.).

  • Group channels are simply collections of standard channels that are opened within a particular connection so that they are addressable through a common communication channel.

Job Negotiation Protocol

Used by a miner to negotiate a block template (which includes the transaction set) with a pool, making pooled mining more similar to solo mining and thus increasing decentralization. The negotiation results can be re-used for all mining connections to the pool (of which there can be hundreds of thousands), greatly reducing the computational intensity.

This protocol is a separate, optional piece of infrastructure from the Mining Protocol and can be provided as a 3rd party service for mining farms.

Template Distribution Protocol

Used to get information about the next block out of Bitcoin Core. This protocol was designed as a much more efficient and easy-to-implement API to replace getblocktemplate (BIPs 22 and 23).

More specifically, the Template Distribution Protocol is used to communicate with a part of Bitcoin Core called “bitcoind” which implements the Bitcoin protocol for Remote Procedure Call (RPC) use. In other words, bitcoind allows the Bitcoin protocol to be integrated with other software.

Job Distribution Protocol

Used to pass newly-negotiated work to interested nodes, which can either be proxies or actual mining devices. This protocol is complementary to the Job Negotiation protocol.

In the case that miners aren’t negotiating their own work (i.e. choosing their own transaction sets), jobs will be distributed directly from pools to proxies and end devices, similarly to in the original stratum protocol. Additionally, it’s possible that the Job Negotiation role will be part of a larger Mining Protocol proxy that also distributes jobs, making this sub-protocol unnecessary even when miners do choose their own transaction sets.

Upstream and downstream describes the direction that data is flowing. The furthest downstream component is a Mining Device, while the furthest upstream component is a Pool Service.

Features

Bandwidth consumption

Stratum V2 is optimized in two ways to reduce bandwidth consumption. First, because it’s completely binary instead of JSON-based like V1, the size of data transfers is minimized. Second, it eliminates many instances where data is being transferred unnecessarily (e.g. redundant messages), meaning that the total amount of data transfers is also minimized.

Stratum V2

V2 typical share submission message is 32 bytes without encryption and 48 with it.

Stratum V1

V1 typical share submission message is approximately 100 bytes

Technical Description

Having a binary rather than text-based protocol reduces bandwidth consumption considerably. Making messages human-readable in Stratum V1 resulted in some messages being approximately 2-3 times heavier than necessary, and those have now been reduced to a minimum size in V2.

Additionally, V1 includes some messages that are unnecessary altogether, such as mining.subscribe. By eliminating these instances, fewer messages need to be transmitted in total and bandwidth consumption is reduced even further.  

Motivation & Impact

Reducing network traffic as well as client-side and server-side computational intensity translates to lower infrastructure costs for all participants. At the same time, a significant reduction in bandwidth consumption allows for hashing results to be transmitted more frequently, enabling more precise hashrate measurement and mining reward distribution as a result.

More detail
Less detail

Server CPU load

With the introduction of standard and group channels for end devices, Stratum V2 enables efficient caching so that server CPUs don’t need to recompute the Merkle root for every share submission. This shifts more responsibility upstream from end mining devices to proxies that connect to pools via extended channels.

Stratum V2

V2 70-80% reduction in CPU load on share submissions vs. V1

Stratum V1

V1 Efficient caching is not possible. The Merkle root is recomputed for every submission.

Technical Description

Reduced server CPU load in Stratum V2 is a result of enabling end devices to do header-only mining. This means that the Merkle root is always provided by an upstream node and doesn’t need to be handled by end devices at all. In other words, end devices no longer have to perform any coinbase modifications. This makes computations simpler for miners, but it also has the consequence of making work validation (i.e. CPU load) much lighter on the server side.

Motivation & Impact

As pool operators ourselves, one of our motivations for reducing server CPU load is probably rather obvious — it reduces our overhead costs. However, any pool can (and should) take advantage of this benefit, so the greater motivation in the big picture is simply to reduce the inefficiency of the entire network.

More detail
Less detail

Job distribution latency

Pools can send jobs to workers ahead of time for future blocks, even before the prior block has been found. Then the pools can send the latest prevhash to the miners in a much smaller (i.e. faster) message, indicating that they should start working on the next block immediately.

Stratum V2

V2 separates the messages, making it possible for the miners to start working on new (full) blocks more quickly after a previous block has been found.

Stratum V1

V1 prevhash and future job are part of the same message, so pools send empty blocks.

Technical Description

Pools distribute jobs to miners by sending blocks containing some predefined data as well as some variable data that the miners handle. In Stratum V1, the predefined data includes the prevhash (i.e. hash of the most recently found valid block) and the Merkle root for the transaction set to be included in the current block. However, these two pieces of data aren’t seperabable, so there is a heavy (slow) data transfer necessary to distribute new jobs as soon as a new block (with a new prevhash) has been found and propagated. In Stratum V2, it’s possible to separate the prevhash from the rest of the predefined block data, which allows for the block data to be sent before a new prevhash is available. As a result, the new prevhash message can be sent on its own as soon as a valid block is found, and this transmission can occur much faster because the message doesn’t include heavier data. This enables miners to begin working on new jobs more quickly than they could with Stratum V1.

Motivation & Impact

Every millisecond that a miner has to wait to begin working on a new job is opportunity (i.e. money) lost. By separating the prevhash message from other job distribution messages in Stratum V2, those precious milliseconds can be saved.

More detail
Less detail

Binary vs. non-binary

Stratum V2 is binary, which means messages are encoded so that machines can read and write them efficiently, but they aren’t suitable for humans to read or work with directly. As a consequence, the size of data transfers between miners, proxies, and pool operators is minimized.

Stratum V2

V2 data transfers are not human-readable, but are significantly more efficient.

Stratum V1

V1 sends human-readable (JSON) data, which helped with adoption and is easier to parse / debug, but is much less efficient.

Technical Description

The protocol has fixed message framing and is precisely defined, which means that there isn’t room for different interpretations of Stratum V2 like there was with V1. The specific message framing structure can be found in the ‘Framing’ section of the BIP.

Motivation & Impact

The original stratum protocol uses JSON, which has a very poor ratio between message payload size and actual information transmitted. Making Stratum V2 a binary protocol yields far better data efficiency, and the saved bandwidth can be used for more frequent submits to further reduce hashrate variance.

More detail
Less detail

Man-in-the-middle attack prevention

To ensure the confidentiality and integrity of sensitive data, Stratum V2 uses a robust encryption scheme that prevents data from being deciphered by potentially malicious third parties. This protects miners from several attacks that are possible in V1, including hashrate hijacking in which a third party intercepts communication between a miner and pool and takes credit (i.e. steals payouts) for the work the miner has done.

Has mechanism(s) to prevent malicious parties from stealing hashrate and eavesdropping on mining data transfers?
Stratum V2

Yes

Stratum V1

No

Technical Description

Stratum V2 employs a type of encryption scheme called AEAD (authenticated encryption with associated data) to address the security aspects of all communication that occurs between clients and servers. This provides both confidentiality and integrity for the ciphertexts (i.e. encrypted data) being transferred, as well as providing integrity for associated data which is not encrypted.

Motivation & Impact

Stratum V1 is vulnerable to man-in-the-middle attacks of three varieties: eavesdropping on all communication between pools and miners, stealing metadata from ISP logs, and hashrate hijacking. These attacks can all be executed without being easily detected, making them all the more troublesome. Stratum V2 uses authenticated encryption with associated data (AEAD) so that possible adversaries will be unable to use share submission data to identify particular miners, thus maintaining the privacy of miners and protecting them against hashrate hijacking.

More detail
Less detail

Empty block mining elimination

In Stratum V2, it is equally as efficient for pools to send full blocks for miners to begin working on as it is for them to send empty blocks (i.e. blocks that don’t contain any transactions). Since there is no extra delay caused by sending a full block, the incenctive to send an empty block is eliminated.

Stratum V2

No extra delay to send a full block vs. an empty block.

Stratum V1

Slower to send a full block than an empty block.

Technical Description

Very similarly to the Job Distribution Latency section, the elimination of the incentive for empty block mining comes down to the separation of the prevhash message from other block header data. With Stratum V1, there is an incentive for pools to send empty blocks containing the new prevhash as soon as possible, as these messages will arrive faster than a message containing a full block. By separating these two messages in Stratum V2, it’s now possible for pools to send full blocks to miners before the new prevhash message. In other words, the miners can be prepared to start working on a new (full) block before the previous block has been found, and then all they need is the new prevhash message to begin working on that next block. Since this prevhash message is the same size (i.e. takes the same amount of time to arrive) regardless of whether or not the pool has sent an empty block or a full block, there is no longer an incentive to mine on empty blocks.

Motivation & Impact

As long as the incentive to mine on empty blocks exists, there is a nonzero chance that a miner will actually find a valid solution during this time and propose an empty block that’s accepted by the rest of the network. Given that there is no advantage to mining on an empty block vs. a full block with Stratum V2, empty block mining should effectively be eliminated.

More detail
Less detail

Job selection

Miners now have the ability to choose their own work (i.e. choose their own transaction set), making mining more decentralized. This is implemented separately from the main mining protocol and is optional for pools and miners.

Allows miners to choose their own transaction set?
Stratum V2

Yes

Stratum V1

No

Technical Description

Job selection by end miners has been included as an optional component of Stratum V2, separate from the main mining protocol. In fact, this is actually done by three sub-protocols: the Job Negotiation Protocol, Job Distribution Protocol, and Template Distribution Protocol.

The name Job ‘Negotiation’ Protocol is telling, as job selection is indeed a negotiation process between a miner and a pool. The miner proposes a block template, and it is up to a pool to accept or reject it. Once a negotiated template has been accepted, the results can be used by any number of mining devices, even hundreds of thousands of them. The reason this is separate from the main mining protocol is to allow pools to terminate connections on seperate infrastructure from the main mining protocol, that way there is no impact on the efficiency of actual share submissions.

Motivation & Impact

Allowing miners to choose their own transaction sets moves some power from mining pools further downstream to the miners themselves, thereby increasing the censorship resistance of Bitcoin. This idea was originally put forth by Matt Corallo in BetterHash, and we felt it was very important to include in Stratum V2 as well because it has a meaningful impact on Bitcoin’s decentralization.

More detail
Less detail

Multiplexing

Allows a single connection (e.g. TCP) to be used for independent communication channels between any number of devices. This reduces the total amount of connections necessary for pools and proxies, resulting in some cost savings.

Has multiplexing?
Stratum V2

Yes

Stratum V1

No

Technical Description

Although it wouldn't be practical, there can theoretically be as many as 232 (~4.3 billion) open channels within a single physical connection (e.g. TCP) to an upstream stratum node. These channels are independent and have unique channel IDs, meaning that many devices can simultaneously receive different job assignments using the same connection, saving on infrastructure costs. At the same time, the channels may all share some information for greater efficiency, such as when a new prevhash is broadcasted.

Motivation & Impact

Every physical connection adds complexity and extra infrastructure overhead to mining operations. Enabling multiplexing makes it possible to communicate a lot of different information to multiple different parties within a single connection, which is more efficient and simpler to manage.

More detail
Less detail

Implicit work subscription

Stratum V2 eliminates some unnecessary messages from V1 by implicitly assuming that opening a mining channel is an indication that the miner is ready to be assigned jobs.

Stratum V2

V2 eliminates the mining.subscribe message.

Stratum V1

V1 there are two messages: mining.subscribe and mining.authorize

Technical Description

When a miner establishes a connection with a pool (client —> server) in Stratum V1, they send a mining.authorize message. Once the authorization request is successful, the miner then sends a mining.subscribe message indicating that they wish to begin (or resume) working on jobs assigned by the pool. In other words, miners must explicitly request job assignments. In Stratum V2, it is implicitly assumed that a miner wants to receive job assignments if they open a channel with a pool.

Motivation & Impact

Mining subscriptions (i.e. the mining.subscribe message) was originally part of a more elaborate mining protocol that is no longer relevant. Currently, explicit mining subscriptions simply create unnecessary data transfers in Stratum V1. Making work subscription implicit improves the relative efficiency of the protocol.

More detail
Less detail

Native version rolling

Version rolling was added as an extension (BIP 310) for Stratum V1. This has become an essential part of mining, and V2 directly supports version rolling by the miners without requiring any extensions.

Stratum V2

V2 natively supports this.

Stratum V1

V1 Has an extension (BIP 310) to allow version rolling 

Technical Description

Each Bitcoin block header contains a version field whose bits can be freely used to extend the search space for a miner. This process is called version rolling. Given the current hashing power of modern ASIC machines, the 32-bit nonce field can be exhausted in under 100ms. Every time this occurs, the controller on the machine must distribute new jobs to each mining chip. This consumes a lot of bandwidth and CPU load. Rolling the version bits can greatly reduce the frequency with which new jobs need to be distributed, and it’s already a common technology (see BIP320). Given it’s prevalent use, we’ve decided to make version rolling a native part of Stratum V2 rather than requiring an extension as it does in V1.

Motivation & Impact

Version rolling is already extremely common and widely adopted. We’ve simply changed it from an extension in Stratum V1 to a native component of the protocol in Stratum V2. The end result from the outside perspective is not much different.

More detail
Less detail

Zero-time backend switching

Zero-time backend switching means that a proxy can provide jobs from different pools without causing a loss of mining efficiency. In other words, a mining farm operator could use a single proxy for all of their devices while mining with multiple pools and they wouldn’t experience any latency or other inefficiencies by doing so.

Stratum V2

V2 natively supports receiving jobs from multiple upstream sources.

Stratum V1

V1 has a non-standard extension that allows miners to change their pool, but the end device needs to explicitly support it.

Technical Description

Enabling miners to do zero-time backend switching (i.e. changing the upstream server from which they are receiving jobs or connecting to multiple upstream servers at once) means that it’s possible to efficiently implement more complicated use cases (e.g. coin switching between Bitcoin and Bitcoin Cash). This can be done with the extraNonce subscription extension in v1, but it’s uncommon and has to be supported in the mining firmware. By making this a native feature of v2, it’s possible for miners on standard channels to receive jobs from multiple sources simultaneously without experiencing any inefficiency compared to receiving jobs from only one upstream server at a time.

Motivation & Impact

Enabling backend switching with zero delays enables more elaborate mining setups to be implemented more efficiently in terms of the physical infrastructure required.

More detail
Less detail

Different type of jobs on the same connection

Allows miners to mine on different jobs (and potentially even different coins) on a single connection. For example, some mining machines could mine Bitcoin while others are mining Bitcoin Cash and they can share the same connection.

Stratum V2

V2 Different channels within the same connection can have different jobs.

Stratum V1

V1 All devices on a connection always share the same job.

Technical Description

One of the specific advantages of multiplexing when it comes to Stratum V2 is that a single physical connection can be used to transmit data about various different jobs. This reduces infrastructure complexity and cost. For example, setting up a TCP connection requires a 3-way handshake in which 3 data packets are transmitted, consuming some resources in the process. When there are hundreds or even thousands of these connections opening and closing each day, the cost can add up. Being able to send different jobs on a single connection reduces the frequency with which connections need to be opened and closed, as well as the total number of connections needed.

Motivation & Impact

As stated above in the Multiplexing section, the primary motivation for enabling data about different jobs to be transmitted on a single connection is to reduce physical infrastructure complexity and overhead costs.

More detail
Less detail

Implementation

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Dolor aliquam eget sit urna. Morbi at at amet sed lorem nisl. Viverra integer id purus sed facilisis eu condimentum nulla.

The Stratum Proxy

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ornare quisque maecenas cursus magna tempus diam.

Link to repository

The mining client

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ornare quisque maecenas cursus magna tempus diam.

Link to repository

Possible Deployment
scenarios

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Lorem ipsum dolor sit amet, onsectetur adipiscing elit. Diam mi sit sed molestie ligula volutpat ipsum risus. Erat ut quam massa velit.

Extensions

The Bitcoin mining industry evolves quickly and it is expected that participants in the industry will wish to add functionality to this protocol over time as extensions. We’ve left extensions largely undefined in the Stratum V2 BIP, but we have outlined some basic requirements which all extensions must comply with/be aware of. These can be found in the Protocol Extensions section.

Pick your number

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.

Pick your number

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.

Pick your number

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.

Currently available extensions

Extension name

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Extension name

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Extension name

Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Technical Description

Protocol extensions in Stratum V2 may be defined by using a non-zero extension_type field in the message header. Extensions in the range 0x4000 - 0x7fff are considered “experimental” and aren’t present in production equipment. Extensions that have been allocated for the specific purpose they address will be present in the ‘Currently Available Extensions’ section of this site.

One of our design goals with Stratum V2 is to enable simple support for vendor-specific extensions without polluting the mining protocol or complicating pool implementation. Thus, it is possible to request extension_type allocations for vendor-specific proprietary extensions to be used in production hardware. To do so, a brief description of the extension’s intended use case should be sent to the Bitcoin Protocol Development List and to extensions@stratumprotocol.org.

For a complete description of requirements for extensions, see the Protocol Extensions section of the Stratum V2 BIP.

Currently available extensions

For a complete description of requirements for extensions, see the Protocol Extensions section of the Stratum V2 BIP.

More detail
A BIP draft has been published and is open for comments from the mining community. Take a look and contribute your input.
Explore the v2 SPecification