Stratum mining protocol
The Stratum mining protocol is a family of protocols used to exchange mining jobs and proof-of-work results between cryptocurrency miners, proxies and pool infrastructure. The original protocol is now called Stratum V1 (SV1); Stratum V2 (SV2) is a separately specified successor with a different message format and security model.[1]
Stratum V1
Stratum V1 was introduced in 2012 and became widely implemented by Bitcoin mining hardware and pools. It replaced repeated getwork polling with a persistent TCP connection over which a pool can push new work to miners.[1][2] V1 commonly uses newline-delimited JSON-RPC-style messages, but its original mining interface was not fully standardized and implementations developed different dialects and extensions.[3]
Core message flow
A typical V1 session uses the following messages. Exact parameters and optional behavior can vary by implementation.[4]
| Direction | Method | Purpose |
|---|---|---|
| Miner → server | mining.subscribe |
Starts or resumes a mining session. The response normally supplies subscription identifiers, an extranonce1 value and the size reserved for extranonce2.
|
| Miner → server | mining.authorize |
Associates a worker name and, where used, a password with the connection. |
| Server → miner | mining.set_difficulty |
Sets the target difficulty for submitted shares. A later job applies the changed difficulty. |
| Server → miner | mining.notify |
Sends a job identifier and the data needed to construct candidate block headers, including the previous-block hash, coinbase parts, Merkle branches, version, target encoding, time and a flag indicating whether old jobs must be discarded. |
| Miner → server | mining.submit |
Submits a worker name, job identifier, extranonce2, time and nonce for validation. The server accepts or rejects the share.
|
Common optional messages include client.reconnect, client.show_message and mining.set_extranonce. BIP 310 defines mining.configure as a negotiation mechanism for extensions including version rolling, minimum difficulty and extranonce subscription.[5] Earlier draft methods such as mining.capabilities were not part of that negotiated extension mechanism and should not be assumed to be supported.
Limitations
The base V1 protocol sends mining traffic in clear text. Research published in 2017 demonstrated that this design could expose hashrate and payout information to passive observers and could permit active traffic-manipulation attacks when an adversary could intercept the connection.[4] Pool-specific TLS tunnels or other protections may change a deployment's exposure, but they are not properties of the base V1 protocol.
V1 normally lets the pool construct mining jobs and select transactions. The miner searches the assigned header space and submits shares; payout accounting, wallets, databases and log rotation are functions of pool software rather than protocol features.
Stratum V2
Stratum V2 uses precisely defined binary messages rather than V1's JSON interface. Its specification defines channels, native version rolling, connection aggregation and separate protocol roles for mining devices, proxies, pools, job declarators and template providers.[3][6]
The suite contains three related subprotocols:[6]
- the Mining Protocol, which distributes work and carries share submissions and is required in every V2 mining arrangement;
- the optional Job Declaration Protocol, through which a miner-side client can propose a selected transaction set to a pool-side service; and
- the Template Distribution Protocol, which carries block-template data from a Bitcoin node to a pool or job declarator.
Job declaration is optional. A pool may use V2 only for pool-selected work, while a deployment using job declaration can let the miner side construct a template and ask the pool to accept it.[6] This changes transaction-selection responsibilities but does not define pool payouts or remove the need to trust a pool's accounting.
V2 protects remote connections with authenticated encryption. The specification uses AEAD and a Noise-based handshake; the secure handshake is mandatory for remote upstream connections and optional on a trusted local link between a device and proxy.[7]
Compatibility and implementations
A translation proxy can accept V1 connections from existing mining devices and use V2 upstream. This provides a protocol bridge; it does not make the downstream device a native V2 implementation. Support for particular V1 extensions or V2 subprotocols must be checked in the miner, proxy and pool being used.
See also
External links
- ↑ 1.0 1.1 Stratum V2 project, “Open Bitcoin mining standard”, checked 14 September 2026.
- ↑ Bitcoin Wiki, “Stratum mining protocol”, checked 14 September 2026.
- ↑ 3.0 3.1 Stratum V2 specification, “Design Goals”, checked 14 September 2026.
- ↑ 4.0 4.1 Maria Apostolaki et al., “Hardening Stratum, the Bitcoin Pool Mining Protocol”, Proceedings on Privacy Enhancing Technologies, 2017.
- ↑ BIP 310, “Stratum protocol extensions”, checked 14 September 2026.
- ↑ 6.0 6.1 6.2 Stratum V2 specification, “Protocol Overview”, checked 14 September 2026.
- ↑ Stratum V2 specification, “Protocol Security”, checked 14 September 2026.