XBT DATUM Mining Pool Setup With Codex

Can a miner with no Linux experience build a private DATUM node and connect XBT miners? Yes. This guide gives candidate XBT/BLAKE2b ASIC owners a model-by-model verification workflow, with one reusable Codex master prompt and our iBeLink BM-S3 deployment as one example.

Our deployment uses a low-cost US VPS and a pruned Bitcoin Knots node. The planned gateway configuration uses CONVOY, Lazarus as the primary XBT DATUM mining pool, and AlphaPool and XorPool as standby profiles. Our test fleet has about ten BM-S3 units at a site without a fixed public IP; the same network layout can be evaluated for other candidate XBT miners after their exact model, firmware and pool protocol are verified.

Deployment status, October 12, 2026: The node is still validating the XBT chain. At the latest check it had validated block 883,719 of 976,785 known headers, with initialblockdownload: true and about 78.5% verification progress. The DATUM Gateway is intentionally stopped. Pool handshakes, failover, and miner share results have not yet been tested. Steps 9–14 below describe the next actions already included in the master prompt; they are not claims that those tests have passed. We will update this article with measured results after verification.

This is an operational guide, not a profitability promise. Endpoints, keys, fees, software, and prices change, so Codex must verify official sources.

Naming note: Here, “XBT” means the BLAKE2b fork commonly called BTCB2; some market listings use BTC2B. Those labels can be confused with ordinary Bitcoin's XBT ticker, so verify the chain and BLAKE2b algorithm before configuring any miner.

Quick Answer: Can a Beginner Build an XBT DATUM Node?

Yes, with clear checkpoints.

You handle identity, payment, CAPTCHA or two-factor authentication, and your public payout address. Codex handles research, configuration, installation, testing, troubleshooting, and documentation.

Never give Codex—or any pool—your wallet seed phrase or private key. Mining only requires a public payout address. Passwords, one-time codes, and payment details should be entered directly into the provider's secure interface, not pasted into a chat.

This is a sequence of evidence-based stages, not one magic command. Repair any failed check before proceeding.

What Is an XBT DATUM Mining Pool, and What Does DATUM Change?

In a conventional pool connection, an ASIC talks directly to a Stratum server. The pool normally constructs the block template and decides which transactions are included. The miner performs the proof of work, but much of the block-construction decision remains upstream.

DATUM changes that relationship through three layers:

1. A local Bitcoin-compatible node validates the XBT chain and builds block templates.
2. A DATUM Gateway converts those templates into work that existing ASIC miners can consume through Stratum.
3. A DATUM-capable pool coordinates shares and pooled payouts without being the sole block-template creator.

Bitcoin Knots validates, CONVOY serves work, and Lazarus is the primary XBT DATUM mining pool. AlphaPool and XorPool are standby choices; individual miners need no full node.

Each miner that passes exact-model, firmware and pool-protocol verification initiates an outbound connection to the VPS, so the mining site's changing public IP is not a problem. A domain is optional.

If you are still comparing the ecosystem, read BTCB2 Mining Pools: How to Decentralize Hashrate and the broader BIP-110 Fork Mining Guide first.

What You Need Before Starting

Prepare the following:

• One candidate XBT/BLAKE2b ASIC for the first test; verify the exact brand, model, firmware and pool protocol before use
• Official miner firmware and access to the miner's web interface
• A public XBT/BTCB2 payout address—never a seed phrase or private key
• A cloud account and a monthly VPS budget of roughly US$8–15
• A computer running Codex with terminal and file access
• Time for native blockchain synchronization and a one-miner observation period

Our test server is a US Contabo Cloud VPS 4 running Ubuntu 24.04 LTS. At purchase, it cost about US$8.20 monthly and included enough SSD capacity for a pruned node, approximately 8 GB RAM, and a 2 GB swap safety margin. Verify current terms before paying.

You can browse candidate models in the BTCB2 miner collection; each model still requires the evidence checks described here. The iBeLink BM-S3 specifications describe our test model; other brands may use different web-interface labels and firmware settings.

Act as the deployment operator for an XBT/BTCB2 DATUM mining setup. Complete the work stage by stage, using current primary sources and measurable evidence. Do not give me a list of prompts to run. Perform every task that can be completed with the access and inputs available, pause only at the human checkpoints defined below, and resume from the recorded checkpoint after I respond.

PROJECT INPUTS
- Target network: XBT/BTCB2 BLAKE2b fork. Verify the chain identity, algorithm, naming and current network parameters before configuring anything.
- Current fleet: approximately 10 iBeLink BM-S3 miners.
- First test device: iBeLink BM-S3.
- First test device firmware: [FILL IN EXACT VERSION]
- VPS provider/plan: Contabo Cloud VPS 4, US region, or [REPLACE WITH SELECTED PLAN].
- Operating system: Ubuntu 24.04 LTS, unless current software support requires another maintained Ubuntu LTS release.
- VPS hostname or public IPv4: [FILL IN PRIVATELY]
- SSH administrator username: [FILL IN]
- Local SSH private-key path: [FILL IN LOCAL PATH; NEVER PRINT OR UPLOAD THE KEY]
- Public XBT/BTCB2 payout address: [FILL IN PRIVATELY; PUBLIC ADDRESS ONLY]
- Primary pool: Lazarus DATUM.
- Standby candidates: AlphaPool and XorPool. Treat AlphaPool support for iBeLink and Goldshell SC models as PASS — OWNER_CONFIRMED, with independent exact-model firmware and accepted-share evidence PARTIAL. Treat XorPool and every other pool/model combination as UNVERIFIED until tested.
- Planned miner-facing port: TCP 42334.
- Node RPC: TCP 8332 on 127.0.0.1 only.
- Gateway management API: TCP 7152 on 127.0.0.1 only.
- Maintenance window: [FILL IN]
- Monthly VPS budget: US$8–15, or [REPLACE].
- Local project directory: [FILL IN].

OPERATING RULES
1. Use official repositories, releases, checksums, documentation, pool endpoints, pool public keys and explorers whenever available. Record each source URL and the check date. Do not rely on remembered versions, fees, prices or endpoints.
2. Never request, reveal, echo, log or commit a wallet seed phrase, private key, SSH private key, password, one-time code, API secret or payment information. Use placeholders in reports and examples.
3. Keep live credentials and the payout address out of Git. Generate secrets locally with restrictive permissions. Sanitize commands, logs and screenshots before saving evidence.
4. Do not equate BLAKE2b algorithm matching with miner compatibility. Compatibility requires exact model, firmware, pool protocol, gateway handshake, miner accepted shares and pool-side credit evidence.
5. Do not claim profitability, payback or guaranteed revenue. If economics are discussed, label them as dated estimates and show assumptions.
6. Use test-first changes, configuration validation, least privilege, atomic deployment and rollback. Do not replace a known-good miner pool profile until its backup settings are recorded.
7. Keep a resumable deployment record containing the current stage, completed checks, failed checks, sanitized evidence paths and the exact next action.

WORKFLOW

Stage 0 — Validate inputs and current sources
- Check that every required input above is present. Ask only for missing values that cannot be discovered safely.
- Verify current VPS specifications and price, supported Ubuntu release, official XBT-compatible Bitcoin Knots release and checksum, official CONVOY repository and commit, current Lazarus DATUM connection requirements, and available AlphaPool/XorPool documentation.
- Produce a short source table with checked date and evidence status. Stop if chain identity or the authoritative software source cannot be established.

Stage 1 — Prepare secure access
- Generate or use a dedicated Ed25519 SSH key without printing the private key.
- Establish key access, create an unprivileged sudo administrator, verify access in a second session, inspect effective sshd settings, and only then disable password authentication if recovery access is proven.
- Preserve a rollback path and record sanitized test results.

Stage 2 — Build the deployment package locally
- Create a manifest for versions, hashes, users, paths, pruning, memory and ports.
- Create example configuration templates for the node and separate Lazarus, AlphaPool and XorPool profiles. Render live values outside Git.
- Add validation, systemd units, a default-deny firewall plan, health checks, log redaction, an atomic pool-switch command and automatic rollback.
- Run local static and configuration tests before changing the VPS.

Stage 3 — Install verified software
- Update required packages only.
- Download Bitcoin Knots from the verified source and verify its published SHA256 before extraction.
- Build CONVOY from a pinned verified commit and record the resulting binary hash.
- Install under unprivileged service accounts with minimal filesystem permissions.

Stage 4 — Apply and verify network security
- Permit rate-limited SSH and the required miner-facing TCP port.
- Bind RPC 8332 and gateway API 7152 to 127.0.0.1 only.
- Confirm externally and locally that management ports are not public.
- Enable appropriate security updates without introducing an uncontrolled service restart.

Stage 5 — Synchronize and verify the XBT node
- Start only the node while initialblockdownload is true; keep the gateway stopped.
- Monitor block/header height, verification progress, peers, pruning, disk and service health at reasonable intervals.
- When synchronization completes, compare height with an independent current explorer, verify chain identity and required BLAKE2b/header-v2 behavior, and prove getblocktemplate succeeds.
- Do not continue if the local chain, explorer and template behavior disagree.

Stage 6 — Start and verify Lazarus
- Re-check the official Lazarus endpoint, port, key, worker/payout format and fee immediately before activation.
- Activate the Lazarus profile and start CONVOY.
- Verify the handshake, current template delivery, service permissions, listening ports and sanitized logs.
- Do not weaken identity or certificate checks merely to obtain a connection.

Stage 7 — Connect one BM-S3
- Confirm the exact BM-S3 firmware and its required pool URL and worker format.
- Present the exact private miner-interface fields with sensitive values represented by placeholders. Pause for me to enter and save them.
- After connection, observe for at least one hour and collect miner, gateway and pool evidence for accepted/rejected shares, hashrate stability, worker visibility and credited work.
- Only a three-sided evidence match can change this exact model/firmware/pool combination to independently verified PASS.

Stage 8 — Migrate the remaining fleet carefully
- Move only devices whose exact model and firmware have passed the required checks.
- Use small batches and record a non-sensitive device label, firmware, start time, hashrate, accepted/rejected shares and rollback state.
- Pause and roll back a batch if rejection rate, missing workers, gateway resources or total hashrate deviates materially from the established baseline.

Stage 9 — Test standby pools and rollback
- Re-verify current AlphaPool and XorPool profiles before use.
- Test manual switch, service validation, accepted shares and pool-side credit with one miner.
- Test automatic rollback using a controlled invalid profile without exposing secrets.
- Preserve OWNER_CONFIRMED, PARTIAL and UNVERIFIED labels until the corresponding technical evidence exists.

Stage 10 — Final security and operations handoff
- Re-run SSH, firewall, bind-address, service-user, file-permission, secret-scan, restart, health-check and rollback tests.
- Produce a sanitized operations guide covering status checks, updates, pool switching, backups, incident recovery and evidence collection.
- Return a final table with PASS, PARTIAL, BLOCKED or UNVERIFIED for every stage and model/pool combination. Include sources, dates, sample duration and evidence paths.

HUMAN CHECKPOINTS
- Stop immediately before any purchase, account creation, login credential entry, CAPTCHA, 2FA, payment, acceptance of a paid plan, or destructive action.
- Stop before inserting the live payout address, VPS address or any secret into a third-party interface; tell me exactly where to enter it without asking me to paste secrets into chat.
- Stop before changing the first miner and before expanding from one miner to a batch. Show the prepared fields, rollback plan and success criteria.
- If a command fails, investigate and repair it, then repeat the relevant verification. Do not skip a failed checkpoint.

Start with Stage 0. First return only: (a) the completed input table, (b) the missing non-secret inputs I must provide, (c) the current primary sources you verified, and (d) the next safe action you can perform now.

Step 1: Review the Inputs and Start the Master Workflow

Start a new Codex task inside a dedicated project folder, fill the marked inputs in the master prompt above, and paste it once. Codex should maintain the checkpoint record and continue through the stages as access and approvals allow.

The first response should contain the completed input table, missing non-secret inputs, verified primary sources, and the next safe action. Stop if Codex requests wallet secrets, exposes RPC, skips checksum verification, or starts all miners before testing one.

Step 2: Select and Buy the VPS

The master workflow compares current plans using current provider pages because pricing and IPv4 terms are time-sensitive.

Check storage, IPv4 fees, setup charges, and contract length—not only the headline price. Record specifications and billing privately; publish only generalized details.

Step 3: Establish SSH Access Before Hardening

The server provider may initially supply a root password. Do not paste it into a normal chat message. The safer goal is to install an SSH public key, prove that key login works in a second session, create an unprivileged administrator, and only then disable password authentication.

Why the effective test matters

On our server, an earlier cloud-init file overrode the intended SSH behavior. Codex detected it with sshd -T, added a regression test, corrected the load order, and proved password-only login failed while key login worked. Evidence matters more than a successful command exit.

Step 4: Research and Pin the Current XBT Software

DATUM implementations are evolving. Before downloading anything, the master workflow verifies authoritative repositories, releases, pool endpoints, public keys, and chain-specific requirements.

Our build pinned Bitcoin Knots 29.4.2.knots20260508 and a specific CONVOY commit. Verify newer releases rather than copying these versions. AlphaPool's retired SV1 route must not be confused with its DATUM implementation.

Step 5: Build a Tested Deployment Package

Do not make the live server your scratchpad. The master workflow prepares configuration templates, validation, tests, and documentation locally first.

Keep only examples in source control. RPC passwords, the live payout address, VPS address, and provider account information must not enter Git.

Step 6: Install and Verify Bitcoin Knots and CONVOY

Once local tests pass, deploy the pinned artifacts to the VPS. Downloaded binaries require checksum verification; source builds require a recorded commit and resulting binary hash.

Our configuration uses a 4 GB pruning target and 2 GB database cache; adjust and document these values for your server.

Step 7: Configure Private RPC, API, and Firewall Rules

The miner-facing Stratum port must be reachable, but management services should not be public. Our design permits public TCP 22 for SSH and TCP 42334 for miners. Node RPC on 8332 and the gateway API on 7152 bind only to 127.0.0.1.

Public port 42334 lets miners on a dynamic connection reach the VPS. Later, WireGuard can reduce exposure if the mine has an always-on router or gateway.

Step 8: Let the Node Complete Native Synchronization

Start only the node. A native initial block download validates the chain from genesis and avoids trusting a third-party snapshot. Pruning limits retained block data, but it does not eliminate validation time.

Synchronization may take hours or longer. An open miner port does not prove the node can create valid current work; keep the gateway stopped.

Step 9: Verify Chain Identity and getblocktemplate

This is the critical chain-specific checkpoint. A generic Bitcoin node that runs without errors may still be wrong for the BLAKE2b/header-v2 XBT network.

Current result: Initial block download is still in progress. The final height comparison, peer count, chain identity, and BLAKE2b/header-v2 getblocktemplate result will be added after synchronization.

Step 10: Start Lazarus as the Primary Pool

Only after the node passes the previous checkpoint should Codex activate the Lazarus profile and start CONVOY.

The miner URL will normally look like this:

stratum+tcp://YOUR_VPS_IP:42334

Replace the placeholder only in the miner's private interface. Redact it from screenshots.

Step 11: Connect One XBT Miner First

Test one ASIC first and retain its known-good backup pool entries.

A green indicator is not enough. Confirm accepted shares at the ASIC, gateway, and pool. Investigate rejections for latency, stale work, worker formatting, firmware, or chain mismatch.

Current result: No miner has been migrated to this gateway yet. Confirm the URL and worker format against the live gateway, selected XBT DATUM mining pool, and device firmware before changing a miner. We will add one-hour share and pool-credit observations after the first test.

For a broader hardware validation process, see the Bitcoin BLAKE2b Fork SC Miner Test Guide.

Step 12: Migrate the Remaining Miners in Small Batches

After the first miner is stable, move the others in small groups so one problem cannot take the farm offline.

Ten miners do not require ten nodes. The VPS validates, constructs templates, and distributes work; monitor its resources and latency as units are added.

Step 13: Test AlphaPool and XorPool With Automatic Rollback

Standby settings are useful only after a real switch and rollback test.

Manual switching is intentional: fees, latency, payout rules, and reliability all matter.

Current result: These live pool handshakes and rollback tests are pending. The standby profiles have been prepared, but a prepared profile does not prove connectivity.

Step 14: Run the Final Security and Regression Review

The last step creates a maintainable handoff.

XBT DATUM Security Checklist

Before calling the deployment complete, confirm every item below:

• Wallet seed phrase and private key were never shared
• Only a public payout address was used
• VPS payment, password, CAPTCHA, and 2FA stayed under human control
• Dedicated SSH key works and its private half remains local
• Effective SSH settings were verified, not assumed
• RPC and management API bind to 127.0.0.1
• Firewall exposes only the required miner and administration ports
• Download checksums and source commits are recorded
• Node and gateway run as unprivileged users
• Native synchronization completed before gateway startup
• Local height matches an independent explorer
• BLAKE2b/header-v2 getblocktemplate succeeds
• One miner passed a monitored test before batch migration
• Each standby profile and rollback path was tested
• Public documentation was scrubbed of IPs, addresses, credentials, and account IDs

Frequently Asked Questions

Do I need a fixed public IP at the mining site?

No. XBT miners initiate outbound connections to the VPS. The VPS needs the stable reachable address; the mining site's public IP can change.

Does DATUM increase the number of validating nodes?

It can encourage more miners to run their own validating and template-building infrastructure, but that is not its only purpose. The key change is moving block-template construction and transaction selection closer to miners while retaining pooled share accounting.

Final Thoughts

A personal DATUM node lets miners construct work from a validated chain while retaining pooled rewards. A fixed-IP VPS also serves mines without a static address.

No Linux background does not have to mean blind trust. Codex turns an XBT DATUM mining pool deployment into reviewable stages, evidence, tests, and documentation.

Start with one miner. Keep secrets out of chat and Git. Require proof at every security boundary. Test rollback before you need it. Only then move the rest of the farm.

If you are planning an XBT mining deployment or need help verifying candidate BLAKE2b hardware, contact BT-Miners for current hardware availability and deployment guidance.

Sources and Further Reading

• CONVOY DATUM Gateway
• AwokenLazarus XBT/Bitcoin repository
• Bitcoin Knots downloads
• Lazarus Pool connection guide
• Bitcoin BLAKE2b resource list and ticker notes
• BTCB2 Mining Pools and Decentralized Hashrate
• BIP-110 Fork Mining Guide