Efficiency improvement for ASIC mining devices that lowers their electricity consumption.
Free and open-source software that includes a full node implementation for Bitcoin.
A Bitcoin client / program that implements the Bitcoin protocol for remote procedure call (RPC) use.
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.
Special field containing the input for the coinbase transaction as well as up to 100 bytes of data available for arbitrary use.
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.
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.
Furthest downstream node; does the actual hash computations, i.e. the proof of work.
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 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.
Furthest upstream node, responsible for generating unique jobs for each connection to the server by putting unique data into the coinbase.
Intermediate node, used for hashrate / difficulty aggregation.
All transactions being included in a proposed block.
Changing the block version value in the first field of the Bitcoin block header, thereby enabling AsicBoost.
The next generation protocol for pooled mining by Pavel Moravec and Jan Čapek, in collaboration with Matt Corallo and other industry experts.
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.
The actual mining machine computing the hashes.
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.
An upstream node to which shares (i.e. completed jobs) are being submitted. The most common hashrate consumers are pools.
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.
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.
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.
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.
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.
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.
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.
V2 typical share submission message is 32 bytes without encryption and 48 with it.
V1 typical share submission message is approximately 100 bytes
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.
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.
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.
V2 70-80% reduction in CPU load on share submissions vs. V1
V1 Efficient caching is not possible. The Merkle root is recomputed for every submission.
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 added benefit of making work validation (i.e. CPU load) much lighter on the server side.
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.
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.
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.
V1 prevhash and future job are part of the same message, so pools send empty blocks.
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.
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.
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.
V2 data transfers are not human-readable, but are significantly more efficient.
V1 sends human-readable (JSON) data, which helped with adoption and is easier to parse / debug, but is much less efficient.
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.
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.
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.
Yes
No
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.
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.
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 incentive to send an empty block is eliminated.
No extra delay to send a full block vs. an empty block.
Slower to send a full block than an empty block.
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.
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.
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.
Yes
No
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.
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.
This is a lightweight version of the mining protocol that allows device firmware to be less complex and consume less bandwidth / CPU load. It is faster and cheaper than the fullweight version but loses some flexibility, so it’s only intended for use by end mining devices.
Yes
No
Stratum V2 introduces the option for miners to open standard mining channels in which they cannot manipulate the coinbase transaction. In other words, end mining devices don't do any extranonce or Merkle path handling. We call this header-only mining. The size of the search space for a device doing header-only mining for a particular value in the nTime field is 2^(NONCE_BITS + VERSION_ROLLING_BITS) = ~280Th, where NONCE_BITS = 32 and VERSION_ROLLING_BITS = 16. This is a guaranteed search space before nTime rolling. The client that opens a particular standard channel owns the entire assigned search space and can split it further (e.g. between multiple hashing boards or individual chips) if necessary.
Stratum V1 was extended to support pooled mining in late 2012, well before there were hundreds of large mining farms with thousands of ASIC machines each. Considering the amount and scale of these large farms today, operations can be simplified and network traffic can be reduced significantly by supporting some simplified mode for mining in as many situations as possible.
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.
Yes
No
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.
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.
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.
V2 eliminates the mining.subscribe message.
V1 there are two messages: mining.subscribe and mining.authorize
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.
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.
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.
V2 natively supports this.
V1 Has an extension (BIP 310) to allow version rolling
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.
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.
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.
V2 natively supports receiving jobs from multiple upstream sources.
V1 has a non-standard extension that allows miners to change their pool, but the end device needs to explicitly support it.
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.
Enabling backend switching with zero delays enables more elaborate mining setups to be implemented more efficiently in terms of the physical infrastructure required.
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.
V2 Different channels within the same connection can have different jobs.
V1 All devices on a connection always share the same job.
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.
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.
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.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.
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 here.
For a complete description of requirements for extensions, see the Protocol Extensions section of the Stratum V2 BIP.
For a complete description of requirements for extensions, see the Protocol Extensions section of the Stratum V2 BIP.
1) Get Braiins OS+ with V2 support and proxy
DOWNLOAD BRAIINS OS+2) Check Slush Pool manual for testing V2 on Slush Pool here
If you have any questions or discover any issues, please contact us.
.svg){kind=small}
Increase hashrate on your Bitcoin ASICs, improve efficiency as much as 25%, and mine on any pool or get 0% pool fees on Braiins Pool.
Reduzca la transmisión de datos entre su granja y el pool en un 95%. Configure el uso paralelo de múltiples pools. Configure un pool de respaldo para toda la granja.
Se centra en hacer más eficientes las transferencias de datos, reducir los requisitos de infraestructura física para las operaciones mineras y aumentar la seguridad
Líderes de la industria en transparencia e innovación, con más de 1.25 millones de BTC minados desde 2010
