Block Templates and the Merkle Root Explained: What the Pool Hands Your Bitaxe

Block Templates and the Merkle Root Explained: What the Pool Hands Your Bitaxe

Your Bitaxe never sees a full Bitcoin block. It never downloads the thousands of transactions a block can carry, and it never decides which ones go in. Yet every hash it produces commits to all of them. That trick — a whole block's worth of transactions squeezed into one small fingerprint the miner can rebuild on its own — is the merkle root, and it is the reason a tiny home miner can do real Bitcoin proof of work over a home internet connection.

A block template is the candidate block a pool's Bitcoin node prepares: the previous block hash, a chosen set of unconfirmed transactions, and a coinbase transaction that pays the finder. All of those transactions are hashed in pairs with double SHA-256, level by level, until one hash is left — the merkle root — which sits inside the 80-byte block header your miner hashes. The pool does not send the transactions themselves over stratum. It sends the coinbase pieces plus a short merkle branch, so your Bitaxe can roll its extranonce, rebuild the merkle root itself, and get a fresh header to search. When the network moves on to a new block, the old template is stale and a new job replaces it. 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 inside a stratum job" lane. If you want the hashing loop itself, read what is a nonce. If you want the reward side of the block, read the coinbase transaction explained. This post sits between the two: how the pool turns a block template into work your miner can do.

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

The pool builds the block; your miner only proves work on its summary.

That summary is the 80-byte header. The merkle root is the field in that header that stands for "every transaction in this block, in this exact order, including the one that pays the finder".

What a block template is

Before anyone can mine, someone has to decide what the next block would contain if it were found. That candidate is the block template. A pool's Bitcoin node assembles it (commonly through the node's getblocktemplate interface), and it holds:

1. The previous block hash. Which block this candidate builds on.
2. A selection of unconfirmed transactions. Taken from the node's mempool, ordered and checked against the consensus rules.
3. The coinbase transaction. The first transaction in the block, which creates the block reward and pays it out. In solo mining this is the transaction built for the find.
4. Header ingredients. Version, time, and the compact target (nbits) the block hash must beat.

Nothing in the template is final until a miner finds a header hash below the network target. Until then it is just a proposal — and it is replaced whenever something important changes.

What a merkle tree is

A merkle tree is a way to turn a long list of items into one short fingerprint, so that changing any single item changes the fingerprint.

Bitcoin builds it from transaction IDs like this:

1. Start with the list of transaction IDs. The coinbase transaction is always first.
2. Pair them up. Join each pair and hash the result with double SHA-256 — the same hash function used for block headers.
3. Repeat on the new list. Each level is roughly half the size of the one below.
4. If a level has an odd number of hashes, the last one is paired with itself. That is, it is duplicated so every hash has a partner.
5. Stop when one hash remains. That single hash is the merkle root.

A simplified picture, with placeholders only:

EXAMPLE ONLY — four transactions, placeholder hashes
Level 0 (txids):   [CB]      [T1]      [T2]      [T3]
Level 1:             H(CB+T1)            H(T2+T3)
Level 2 (root):              H( H(CB+T1) + H(T2+T3) )   -> merkle root in header

Change the coinbase, change any transaction, or change the order, and the merkle root comes out completely different — so the block header changes, and so does every hash your miner computes from it.

Why the merkle root is in the header

The block header is only 80 bytes. It contains the version, the previous block hash, the merkle root, the time, the compact target, and the nonce. The merkle root is how those 80 bytes commit to the whole block.

That is what makes proof of work meaningful. A miner cannot find a good header hash and then quietly swap the transactions afterwards, because the merkle root would no longer match. Anyone checking the block recomputes the root from the transactions and confirms it equals the one in the header.

What the stratum job actually carries

Here is the practical part. If the pool sent every transaction to every miner, home connections and tiny controller boards would struggle. Instead, the stratum mining.notify job carries just enough to rebuild the merkle root:

1. A job ID. So shares can be matched to the job they came from.
2. The previous block hash.
3. Two halves of the coinbase transaction (often called coinb1 and coinb2). The miner's extranonce goes between them.
4. The merkle branch. The list of sibling hashes needed to walk from the coinbase up to the root.
5. Version, nbits, and time.
6. A clean-jobs flag. Tells the miner whether to drop older work immediately.

EXAMPLE ONLY — simplified mining.notify, placeholder values
mining.notify  job_id=<JOB>  prevhash=<PREV>  coinb1=<C1>  coinb2=<C2>
               merkle_branch=[<B1>, <B2>, <B3>, ...]  version=<V>  nbits=<BITS>  ntime=<T>  clean_jobs=<true|false>

Notice what is missing: the transactions themselves. The merkle branch replaces them.

The merkle branch: rebuilding the root without the transactions

Because the coinbase transaction is always the first leaf of the tree, its path to the root is predictable. At each level, the coinbase-side hash only needs one partner — the sibling hash from the other side. The merkle branch is exactly that list of partners, from the bottom up.

So your Bitaxe can do this on its own:

1. Join coinb1 + extranonce1 (assigned by the pool) + extranonce2 (rolled by the miner) + coinb2 into the full coinbase transaction.
2. Double SHA-256 it to get the coinbase hash.
3. Combine it with the first branch hash and double SHA-256 again.
4. Repeat with each remaining branch hash.
5. The final result is the merkle root for this exact coinbase.

The branch is short. Its length grows roughly with log2 of the number of transactions, so even a full block needs only a handful of branch hashes. That is the elegant part: a small list lets a small device commit to a large block.

EXAMPLE ONLY — rebuilding the root, placeholder values
coinbase   = <C1> + <EXTRANONCE1> + <EXTRANONCE2> + <C2>
h          = dSHA256(coinbase)
h          = dSHA256(h + <B1>)
h          = dSHA256(h + <B2>)
h          = dSHA256(h + <B3>)
merkle_root = h   -> placed into the 80-byte header -> nonce search begins

Why rolling the extranonce gives fresh work

The nonce field in the header has a limited range. When the miner has tried it all for one header, it needs a new header. The easiest way is to change the coinbase: roll extranonce2, rebuild the merkle root with the branch, and the header is new. Every nonce is fresh again.

This is why the coinbase and the merkle root are so tightly linked to mining. The coinbase is not just "the reward transaction" — it is also the miner's source of extra search space. The nonce side of this is covered in what is a nonce.

When the template changes

A block template does not live forever. The pool sends a new job when:

1. A new block appears on the network. The previous block hash changes, so all old work is now building on the wrong tip. The new job usually has clean_jobs set so the miner drops the old one at once.
2. The pool refreshes the transaction set. New transactions arrive in the mempool, so the template can be rebuilt with a different selection. The merkle branch changes.
3. Time moves on. Header time can be updated within the rules.

If a share is submitted for a job that has already been replaced, the pool may reject it as stale. That is normal at block changes, and only a concern if it happens often — see stale shares fix.

Solo context: whose template is it?

In pool mining, many miners work on the same template and share the result. In solo mining on Bitmern Solo, your shares are attributed to your WALLET.worker, and the find is credited to that worker's payout wallet. You do not need to build or check templates yourself — the pool's node does that. What you control is the connection and the identity: host, port, username, password.

For what happens after a winning header, read what happens when you find a block. For how the reward is structured, read the coinbase transaction explained.

Ordered "is my miner getting good jobs?" checklist

You cannot see the merkle tree in AxeOS, but you can confirm every step around it.

1. Confirm the stratum fields

Symptom: You are not sure the miner is pulling jobs from Bitmern Solo.

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.

2. Watch new jobs arrive in the logs

Symptom: Hashrate looks fine, but you want proof the miner is receiving fresh templates.

Fix: Open the AxeOS logs. You should see new job lines arriving from the pool, with bursts around new network blocks. The AxeOS logs guide shows what normal job and share lines look like.

3. Confirm shares are accepted

Symptom: Jobs arrive, but you are not sure the miner's rebuilt headers are valid.

Fix: Open the matching coin tab on Bitmern Solo and look at your worker. Accepted shares mean the miner rebuilt the coinbase, merkle root, and header correctly — otherwise the pool could not verify them. See share difficulty explained.

4. Read occasional stale shares as normal

Symptom: A few stale rejects show up around block changes.

Fix: That is a share racing a template switch. Keep the miner on stable wired or strong Wi-Fi. If stale rejects are frequent, work through stale shares fix.

5. Leave the template to the pool

Symptom: You wonder whether you should pick transactions or tune anything.

Fix: You do not. Firmware handles extranonce2 and merkle rebuilding; the pool's node handles the template.

6. Read Current Effort correctly

Symptom: Current Effort is high and you think the next template must be "the one".

Fix: Every template and every hash is an independent chance. Current Effort is not a find guarantee — read Current Effort explained.

A worked example of the flow (EXAMPLE values only)

The steps below use placeholders to show the sequence only.

EXAMPLE ONLY
pool node   builds template: prev=<PREV>, txs=[CB, T1 ... Tn], nbits=<BITS>
pool        computes merkle_branch for CB, splits coinbase into <C1>/<C2>
pool -> miner   mining.notify job=<J1> ... clean_jobs=true
miner       extranonce2=<E1> -> coinbase -> merkle root R1 -> header -> nonce search
miner       nonce range exhausted -> extranonce2=<E2> -> merkle root R2 -> new header -> search again
miner -> pool   mining.submit WALLET.worker <J1> <E2> <T> <NONCE>   (share accepted)
network     new block found elsewhere
pool -> miner   mining.notify job=<J2> prev=<NEW> ... clean_jobs=true   (J1 work dropped)

What this post will not invent

• No transaction counts, block sizes in use, or branch lengths for real blocks
• No claims about how Bitmern Solo selects transactions internally
• No profitability, ROI, or price talk — no financial advice
• No claim that :3102 is the home Bitaxe default (easy-start is :3132)

Common merkle and template misunderstandings

1. "My Bitaxe downloads the whole block." It does not. It receives the coinbase pieces and a merkle branch.
2. "The merkle root is a checksum I can ignore." It is the header's commitment to every transaction; without it, proof of work would not protect the block's contents.
3. "Shares from an old job count toward the new block." They do not. A new previous block hash means a new template.
4. "Extranonce and nonce are the same thing." The nonce is in the header; the extranonce is in the coinbase and changes the merkle root.
5. "A better template makes a find more likely." Odds come from hashrate versus network difficulty, not from which transactions are inside.
6. "High Current Effort means a block is coming." It does not. Current Effort is not a find guarantee.

Soft next step

Open AxeOS, confirm the stratum fields above, and glance at the logs as a new job arrives. Then open the matching coin tab on Bitmern Solo and watch accepted shares appear under your WALLET.worker. Each one means your miner took the pool's template, rebuilt the merkle root, built a header, and proved work on it. 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 a merkle root in Bitcoin?

A single double SHA-256 fingerprint of every transaction in a block, built by hashing transaction IDs in pairs up a tree. It sits in the 80-byte block header.

What is a block template?

The candidate block a pool's node prepares: previous block hash, a chosen set of transactions, the coinbase transaction, and header ingredients. Miners prove work on its header.

What is a merkle branch in stratum?

The list of sibling hashes a miner needs to rebuild the merkle root from the coinbase transaction, without receiving the other transactions.

Why does the pool send new jobs so often?

New network blocks make old templates obsolete, and refreshed transaction sets change the merkle branch. New jobs keep your miner working on a current candidate.

Do I need to configure anything for merkle roots?

No. Firmware and the pool handle it. You only set host, port, WALLET.worker, and password x.

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.