The Stratum Protocol Explained: How Your Bitaxe Talks to a Solo Pool

The Stratum Protocol Explained: How Your Bitaxe Talks to a Solo Pool

You type three things into AxeOS — a host, a port, and a username — and a few seconds later your Bitaxe is hashing real Bitcoin work. Between those two moments, your miner and the pool hold a short, structured conversation. That conversation has a name: Stratum. Once you know what it says, most "why is my miner not working" questions stop being mysterious, because almost every connection problem is one line of that conversation failing.

Stratum is the protocol miners and pools use to exchange work. In the widely used version (Stratum V1), your miner opens one long-lived outbound TCP connection to the pool and both sides send small JSON messages, one per line. The miner subscribes (mining.subscribe), logs in with its username and password (mining.authorize), receives a share difficulty (mining.set_difficulty) and jobs (mining.notify), and sends back shares that meet that difficulty (mining.submit). The pool answers each share with accepted or rejected. Nothing about Stratum requires you to open inbound ports at home. On Bitmern Solo, keep BTC easy-start host btc.bitmernsolo.com with port :3132 (never treat :3102 as the Bitaxe / home default), username WALLET.worker, password x. Current Effort is not a find guarantee.

This is the "what is actually being said on the wire" lane. If you want what is inside a job, read block templates and the merkle root explained. If you want the hashing loop your miner runs on each job, read what is a nonce. This post covers the connection that carries both.

Bitmern Solo is solo infrastructure: flat 1% fee on finds only, you keep 99%. Nothing in this post is financial advice, and nothing here promises a find.

The one-sentence version

Stratum is a phone line your miner keeps open to the pool: the pool reads out work, the miner reads back proof.

Everything else is detail about who says what, and in which order.

Why mining needs a protocol at all

A Bitcoin block can only be found by hashing a block header. Building that header means knowing the previous block, the transactions, and the coinbase transaction that pays the finder. A home miner does not run a full node, does not hold a mempool, and should not have to. So the pool does the bookkeeping and the miner does the hashing.

That split only works if the two sides agree on a format for:

1. Who is mining — which wallet and worker should get credit.
2. What to mine — the current job, built from a block template.
3. How hard each proof should be — the share difficulty.
4. What the miner found — shares, and in the rare best case, a block.

Stratum is that agreement. It replaced an older approach where miners repeatedly asked a node for work over HTTP. Keeping one connection open and letting the pool push new jobs is far more efficient, which is why practically every modern pool and ASIC firmware speaks it.

What the connection looks like

In Stratum V1:

• Transport: a plain TCP connection from your miner to the pool host and port.
• Direction: the miner dials out. The pool never dials in to your home. That is why you do not need port forwarding — see no inbound ports needed.
• Format: JSON-RPC style messages, one message per line.
• Lifetime: the connection stays open for as long as the miner is running. If it drops, the miner reconnects and starts the conversation again.

The stratum+tcp:// you sometimes see in front of a host is just a label for "this is a Stratum connection over TCP". Whether your firmware wants it typed in depends on the firmware — read the stratum+tcp prefix before you add or remove it.

The conversation, step by step

1. mining.subscribe — "I want work"

The first thing your Bitaxe sends after connecting. The pool replies with:

• a subscription identifier,
• extranonce1 — a value unique to this connection,
• extranonce2 size — how many bytes of extra search space the miner may roll itself.

Extranonce1 is what keeps two miners on the same pool from ever hashing the exact same header. Extranonce2 is the miner's own private dial: changing it changes the coinbase transaction, which changes the merkle root, which gives a fresh header to search once the nonce range is exhausted.

2. mining.authorize — "this is who I am"

The miner sends its username and password. On Bitmern Solo that is:

WALLET.worker

and

x

The wallet part says where a find is credited. The worker part is a label so you can tell your miners apart — see the worker naming guide. The password x is a placeholder the protocol expects; it is not an account password. Read why the stratum password is x.

If authorization fails, nothing else matters: the miner may stay connected but its work is not attributed. A wrong or malformed wallet is the usual cause — see invalid wallet rejects.

3. mining.set_difficulty — "this is how hard a share must be"

The pool tells the miner the minimum difficulty a hash must reach to count as a share. Shares are not blocks. They are proof that your miner is doing real work against real jobs, at a difficulty far below the network's block target.

The pool can raise or lower this number over time to keep share flow steady. That is VarDiff, and it is why the port you pick matters. Read share difficulty explained and VarDiff and stratum ports.

4. mining.notify — "here is a job"

This is the message that carries the work. A job includes:

• a job ID,
• the previous block hash,
• two halves of the coinbase transaction (the miner places extranonce1 and its own extranonce2 between them),
• the merkle branch — just enough hashes to rebuild the merkle root without every transaction,
• the block version, the compact target (nbits), and the time (ntime),
• a clean jobs flag.

When the clean jobs flag is set, the miner should drop older jobs immediately — usually because the network found a new block and all earlier work now builds on a stale tip. When it is not set, the new job is an update (for example, a refreshed set of transactions) and older jobs may still be finished.

5. mining.submit — "here is a share"

When your Bitaxe finds a hash that beats the share difficulty, it sends back:

• the worker name,
• the job ID,
• the extranonce2 it used,
• the ntime it used,
• the nonce that produced the hash.

From those values the pool rebuilds the exact header and checks the hash itself. The miner never has to be trusted. The pool replies accepted or rejected.

If that same hash also happens to beat the network target, the pool has a valid block — and in solo mining, the coinbase in that job is the one built for your find. Read what happens when you find a block.

Optional: mining.configure

Many modern ASIC firmwares negotiate extensions right after connecting, most commonly version rolling (letting the miner change some bits of the block version for extra search space). You do not configure this by hand; the firmware and pool agree on it.

Where each common problem lives in the conversation

Symptom Where it breaks Read Stuck "connecting" TCP connection never opens (host, port, DNS, Wi-Fi) stuck connecting Connects then drops Connection opens but times out or resets stratum timeout fix Authorized but not hashing Subscribe/authorize OK, no shares follow authorized but not hashing Shares rejected mining.submit answered with reject rejected shares fix Stale shares Share arrived for a job the pool already replaced stale shares fix Worker missing on dashboard Username not what you think it is workers not appearing

Reading problems this way is faster than guessing. Your AxeOS logs usually show exactly which step was the last one to succeed.

A sample exchange (EXAMPLE values only)

EXAMPLE ONLY — placeholder values, shortened
miner -> pool  {"id":1,"method":"mining.subscribe","params":["firmware/x.y"]}
pool  -> miner {"id":1,"result":[[...],"EXTRANONCE1",EXTRANONCE2_SIZE],"error":null}
miner -> pool  {"id":2,"method":"mining.authorize","params":["WALLET.worker","x"]}
pool  -> miner {"id":2,"result":true,"error":null}
pool  -> miner {"id":null,"method":"mining.set_difficulty","params":[SHARE_DIFF]}
pool  -> miner {"id":null,"method":"mining.notify","params":["JOB_ID","PREVHASH","COINB1","COINB2",[BRANCH...],"VERSION","NBITS","NTIME",true]}
miner -> pool  {"id":3,"method":"mining.submit","params":["WALLET.worker","JOB_ID","EXTRANONCE2","NTIME","NONCE"]}
pool  -> miner {"id":3,"result":true,"error":null}

You never need to type any of this. It is here so the words in your logs — subscribe, authorize, notify, submit — map to something concrete.

What about Stratum V2?

Stratum V2 is a newer, separate protocol. It uses a compact binary format instead of JSON lines, encrypts the connection, and is designed so that, where supported, miners can take part in choosing the transactions in their own templates. It is not a drop-in setting you switch on in AxeOS today; it needs support on both the miner side and the pool side. For a Bitaxe on Bitmern Solo, the setup below is what you use.

Ordered "Stratum health" checklist

1. Confirm the stratum fields

Symptom: You want to rule out typos before anything else.

Fix: In AxeOS, check the stratum settings. Host:

btc.bitmernsolo.com

Port:

3132

Username:

WALLET.worker

Password:

x

Never treat :3102 as the Bitaxe / home default. If anything here looks unfamiliar, read stratum URL mistakes.

2. Check the connection step

Symptom: The miner never gets past connecting.

Fix: That is the TCP step. Check Wi-Fi signal, DNS, and whether a router feature is blocking outbound traffic — see firewall blocking stratum.

3. Check the authorize step

Symptom: Connected, but no worker on the dashboard.

Fix: The username is what the pool sees. Make sure the wallet part is valid for the coin and the worker part is what you expect.

4. Check that jobs and shares flow

Symptom: You want proof the whole loop works.

Fix: Open the matching coin tab on Bitmern Solo and look for fresh accepted shares under your worker. Accepted shares mean every step — subscribe, authorize, difficulty, notify, submit — is working.

5. Keep the connection stable

Symptom: Frequent reconnects in the logs.

Fix: Each reconnect restarts the conversation and can waste work on stale jobs. Wired or strong Wi-Fi helps — see reconnect loops fix.

6. Read Current Effort correctly

Symptom: Everything is healthy and Current Effort is high, so a find feels due.

Fix: Current Effort is not a find guarantee — read Current Effort explained.

What this post will not invent

• No latency, share-rate, or job-frequency figures for Bitmern Solo
• No claims about Bitmern Solo's internal server setup or Stratum V2 support
• No price, profitability, or ROI figures — no financial advice
• No claim that :3102 is the home Bitaxe default (easy-start is :3132)

Common Stratum misunderstandings

1. "The pool connects to my miner." It does not. Your miner dials out; no inbound ports are needed.
2. "The password protects my account." On Bitmern Solo it is just x; the protocol expects a value there.
3. "A share is a small block." A share is proof of work at a much lower difficulty. Only a hash that beats the network target is a block.
4. "My miner downloads every transaction." It receives a merkle branch and rebuilds the root itself.
5. "Rejected shares mean the pool is cheating." The pool checks every share the same way; rejects have specific causes you can trace.
6. "High Current Effort means a block is coming." It does not. Current Effort is not a find guarantee.

Soft next step

Open AxeOS and confirm the four stratum fields above, with the wallet you want paid in WALLET.worker. Then open the matching coin tab on Bitmern Solo and watch accepted shares arrive — each one is a finished round of the conversation you just read about. Keep BTC easy-start btc.bitmernsolo.com with port :3132 and password x.

Start mining

Start Mining — after login, open the matching coin tab and confirm workers / shares / hashrate.

FAQ

What is the Stratum mining protocol?

The protocol miners and pools use to exchange work. In Stratum V1, the miner keeps one outbound TCP connection open and both sides send JSON messages, one per line.

What does mining.notify do?

It sends a new job: previous block hash, coinbase halves, merkle branch, version, nbits, ntime, and a clean jobs flag that tells the miner whether to drop older work.

What does mining.submit send?

The worker name, job ID, extranonce2, ntime, and nonce, so the pool can rebuild the header and check the share itself.

Do I need to open ports for Stratum?

No. The miner connects outbound to the pool. See no inbound ports needed.

Is the Bitmern Solo fee taken per share?

No. It is a flat 1% fee on finds only — you keep 99%.

Does Current Effort mean I am about to find a block?

No. Current Effort is an ops / attribution signal — not a find guarantee. See Current Effort explained.