Verify who is building your block templates

DATUM branding, a big pool name or a healthy share counter do not prove that your miner hashes a template you chose. Proof comes from three things: the configuration, the logs, and what the hardware does when you remove a piece of the chain on purpose. This checklist covers all three, in order.

A block template is the candidate block: which transactions go in, and the payout outputs. In pooled mining the pool has traditionally built it and the hardware has only hashed it. We back the opposite arrangement, where a pool coordinates rewards while miners keep control of the template, because whoever picks the transactions can delay or drop the ones they dislike. The conceptual DATUM explainer covers the why. Here we only verify the how.

The path you are tracing

In a DATUM setup, the DATUM Gateway reaches out to a local Bitcoin node for block templates, turns them into work for mining hardware, and submits solved blocks to the network directly. Its documentation says the work it gives to hardware is generated only from the local node's templates. If the miner wants pooled rewards, the gateway also talks to a DATUM-supporting pool. That pool coordinates the reward split based on your work, but according to the documentation it does not create work for you.

That gives you a clear chain to audit: node → gateway → miner, with the pool beside it handling payout coordination. Your job is to confirm each link, and to confirm that nothing else can feed the miner a job.

Run the loss tests only on a non-production setup. Stopping a node, blocking a pool connection or changing failover settings on a live miner interrupts hashing and may cost you work. Keep RPC usernames, passwords and any keys out of screenshots, pasted logs and forum posts. You never need to share a private key for any step here.

Step 1: confirm versions and chain compatibility

Start with the chain, because a template from the wrong chain proves nothing. Bitcoin BLAKE2b is not SHA256d Bitcoin, and a node that follows the wrong rules will not give you valid work.

The miners guide on bitcoin-blake2b.org is the reference for current requirements. At the time of research, its chain guide specified:

  • Node: the BLAKE2b-enabled Bitcoin Knots build, version 29.4.2 for mainnet. Bitcoin Core, or older Knots on the legacy SHA256d chain, does not qualify.
  • Gateway: the CONVOY build of DATUM Gateway, containing commit 56c31f4 or later.

Recheck both against the current guide and the gateway's versioned source before you rely on them. Record the exact node version string and the gateway build or commit you are running. Also compare your node's chain tip with an independent observation, such as the BlakeStack dashboard. Matching tips are only a sanity check, since the dashboard does not measure template ownership.

Step 2: identify the local getblocktemplate source

The gateway fetches templates from the node through the getblocktemplate RPC. Check two things.

  1. The node advertises BLAKE2b. Call getblocktemplate on your node with your usual RPC client and the rules the chain guide specifies, and confirm the returned rules include !blake2b. The gateway documentation says that if GBT does not advertise !blake2b, the gateway serves no work. If this check fails, fix the node before testing anything else.
  2. The gateway points at your node. Open the gateway configuration and find the RPC host and port it uses. Confirm they resolve to the machine you control, not to a remote or shared node. Redact credentials before saving a copy of the file.

Then check the solo versus pooled settings. According to the guide, solo operation needs datum.pool_host empty and datum.pooled_mining_only set to false. Clearing the host while leaving pooled_mining_only true makes the process exit. Confirm key names and defaults in the README for your gateway version rather than trusting this summary.

Also list every Stratum endpoint your miner can reach. The gateway is only one. If the hardware has a second or third pool address in its settings, that is a possible job source you have to account for.

Step 3: trace provenance in logs and configuration

Read the gateway log from startup through a few found-share events. Use the log lines your version actually emits, and check the README and source for what they mean instead of searching for field names you have only heard about. Aim to answer:

  • Which node did the gateway connect to, and did it report fetching templates from it?
  • Did the pool connection come up, and does the log treat it separately from template fetching?
  • Which address does the miner's own interface show as its active pool or worker connection?

The separation matters. A pool can send a payout split, which is the generation transaction outputs, for a template you build locally. Seeing pool traffic therefore does not mean the pool supplied your transactions.

Be careful with share counters too. The README separates shares accepted by the gateway from shares accepted by the pool. Accepted shares on an ASIC or gateway page show that a connection is working. They do not show pool credit, and they do not show who built the template. One accepted share, or one block on chain, cannot prove that every miner in a setup uses local templates either.

If you find a block, compare the gateway's BLOCK FOUND hash with your node's new tip. Older gateway builds have reported block-found work whose hash disagreed with Knots, and a duplicate result on second submission can be normal. Treat a mismatch as a reason to check your gateway version, not as proof of either outcome.

Step 4: run controlled loss tests

A setup that works is not yet verified. Failure behavior tells you who else is in control, so break one link at a time on a non-production rig and write down what the hardware does.

Test What to do What to record
Local node loss Stop the node, or block the gateway's access to its RPC port. Does the gateway stop issuing new work? Does the miner go idle, or does it keep hashing against some job? Which connection does it show?
Pool connection loss Block the gateway's route to the pool while the node stays up. Does the gateway disconnect its Stratum clients? Does the miner switch to another endpoint?
Gateway loss Stop the gateway process. Which backup address does the miner move to, and is it a DATUM gateway or a public pool endpoint?

What the documentation suggests you will see: since gateway work comes only from the local node's templates, losing the node should leave the gateway with nothing to hand out. By default, if the pool connection is lost and fails to reconnect, the gateway disconnects all its Stratum clients.

That is the point to watch. If the miner's failover is a non-DATUM Stratum endpoint, it may be hashing a job the pool built. A common mistake is treating a busy dashboard after an outage as proof that nothing changed. Check the miner's active pool address, and the pool's own terms, since DATUM support, payout rules and failover behavior vary by pool. The published pool terms are a starting point, and they are no substitute for your own test.

For each test, write one of three results: work stopped, work moved to another DATUM gateway you control, or work moved to a pool-built job source. Only the first two preserve template control.

Step 5: restore normal operation and keep the evidence

Bring the links back in reverse order: node, then gateway, then pool access, then the miner. Wait for the node to reach the chain tip and for the gateway to resume fetching templates. Confirm that the miner returns to your gateway rather than staying on a failover address. Remove any temporary firewall rules or settings you used for testing.

Keep a short record you can compare after upgrades:

  • Node version, gateway build or commit, and the date you checked them against the current guide.
  • Confirmation that the node's getblocktemplate rules include !blake2b.
  • The gateway's node target and the solo or pooled settings, with credentials removed.
  • Every Stratum endpoint configured on the miner, in priority order.
  • The outcome of each loss test: stopped, local fallback, or pool-built fallback.

If the fallback turns out to be a pool-built source, you have a choice. You can remove that endpoint so an outage means silence rather than someone else's transactions, or you can accept it knowingly. Either way the decision should be yours, and written down. When you choose a pool, check how it handles failover before you commit hashrate to it.