Stratum V1
Overview
en
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.
Stratum V2 – mining protocol
b
Note: Before you dive into the technical details, be sure that you understand the Terminology we’ll be using.
Protocol Overview
Device
Hashrate Consumer
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.
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.
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).
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.
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.
Jump to feature
Stratum V1
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.
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.
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.
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 consequence 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.
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.
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.
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.
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.
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.
Yes
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.
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 incentive to send an empty block is eliminated.
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.
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.
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.
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.
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.
Header-only mining
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
Cambio en tiempo cero de back-end
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.
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.
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.
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.
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.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Faucibus morbi morbi amet sed. Id elit aliquam aliquam.
Extension name
Extension name
Extension name
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.
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.
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.
For a complete description of requirements for extensions, see the Protocol Extensions section of the Stratum V2 BIP.
A spec draft has been published and is open for comments from the mining community. Take a look and contribute your input.
Explore the v2 SPecification
Explore the v2 SPecification
2) Check Slush Pool manual for testing V2 on Slush Pool here
If you have any questions or discover any issues, please contact us.BACK TO MENU
La primera Pool minera del mundo
.svg){kind=small}
Firmware de minería de código abierto
Aumente la tasa de hash en sus ASIC de Bitcoin, mejore la eficiencia hasta en un 25% y obtenga tarifas de pool del 0% en Slush Pool.
Mejoras de calidad que incluyen cargas de datos reducidas, eliminación de bloques vacíos, prevención de secuestro de hashrate y más.
Actualizaciones de Producto
%20(1).jpg)