Paste your BTX payout address, your address.worker string, or just a worker name to see only your own rig's data. Other miners are hidden. All lookups happen in your browser — nothing is sent to the pool beyond the existing dashboard poll. Address and txid links go to explorer.btxbyronbay.com.

What the POOL HEALTH cells mean

NODE LINK tracks the age of the most recent successful getblocktemplate RPC call from the pool's internal job_pump (which polls every 10s). Green when <30s old, amber 30-90s, red >90s. The sub-line shows rpc_error_count_session — cumulative RPC failures since the pool process started. Red here usually means btxd is down, the cookie auth path is broken, or there's a network partition between the pool box and the BTX node.

JOB ENGINE tracks how long since the pool broadcast a clean=true mining.notify — i.e. when a new block was last detected on the chain. Green <5 min (well within BTX's ~2 min target block time), amber 5-15 min, red >15 min. Sub-line shows the current job_id. Red usually means the chain is stuck or the job_pump task has stalled; cross-check NODE LINK to disambiguate.

COINBASE READY is a boolean: green ● yes when the current job's coinbase script has resolved (block submission is enabled), red ● NO when it hasn't (found blocks will be detected but won't be assembled and submitted to btxd). Red here means the operator should check the coinbase_address in pool.toml — either it's unset or btxd's validateaddress rejected it.

What ACCEPT RATE thresholds mean

Green ≥99%, amber 97-99%, red <97%. The metric is accepted ÷ (accepted + rejected) over the current pool session (resets on every pool restart). Rejects are mostly stale shares from a small set of contention-affected rigs, so the pool-wide rate is dominated by the worst offenders. If this drops below 97% during normal operation, drill into the MINERS view and look at the REJECTS column to identify which worker is producing the bursts.

How to read reject classes

The pool rejects shares for four reasons (all logged at DEBUG level in journalctl -u byron-pool with note=<reason>):

stale share — the share's job is no longer current (a new block was found and the pool moved on). Most common reject class on rigs with network jitter or GPU contention. Bursty pattern: e.g. 9 shares in 200ms all for the same old job.

duplicate — the share's fingerprint matches one the pool already credited. Indicates a buggy or replaying miner; very rare on byron-miner. Single hits, not bursts.

digest above share_target — the miner submitted a nonce whose recomputed digest doesn't actually meet the pool's share target. Indicates either a buggy verifier on the rig OR a corrupted nonce in transit. Investigate if it's more than ~1 per 10k shares.

malformed/structural — the submit message itself was invalid (bad job_id, bad nonce hex, wrong arity). Indicates a protocol bug. Should be zero in steady state.

Common runbook snippets

Restart a rig's miner without touching the system (Linux/CUDA, has supervise.sh):

pkill -x byron-miner   # supervise.sh respawns within ~30s

Retune a Mac knob without re-onboarding:

curl -fsS https://btxbyronbay.com/dl/retune-mac.sh | bash -s -- --gpu-inputs 1

Move a rig from one-result to continuous mode:

curl -fsS https://btxbyronbay.com/dl/apply-continuous.sh | bash

(Requires the rig's running cmdline to already have the Step-B flagship knobs: --gpu-inputs 1, --batch-size 512, --solver-threads 8, --prepare-workers >0. Otherwise the script aborts with a clear error.)

Check what your rig is doing:

tail -f ~/byron-miner.log               # apply-continuous's log path
tail -f /workspace/byron-pool-rig/miner.log   # Runpod supervise.sh path
journalctl -u byron-pool -f              # pool-side, requires SSH to pool box

Rollback apply-continuous on a rig:

bash /workspace/byron-pool-rig/rollback-continuous.sh   # or wherever rig dir is

What counts for payout?

Only pool-accepted shares count. The pool runs PPLNS (Pay-Per-Last-N-Shares): when btxd accepts a block we submit, the full block reward (minus the pool fee, default 1.5%) is split across the last N accepted shares in the rolling window, weighted by who submitted them. The window size is shown as PPLNS WINDOW on Overview.

Rejects don't dock your balance — they're observability only. Submitting more rejects just means your rig burned compute that didn't translate into PPLNS weight.

Which retune script should I use?

Three different tools for three different jobs — do not cross-run them between platforms:

• Mac / Metal rig (Apple Silicon, byron-solve on Metal): use /dl/retune-mac.sh for parameter retunes.
• Linux / NVIDIA CUDA rig (byron-solve2 or btx-gbt-solve on Linux): use /dl/retune-cuda.sh for parameter retunes. This is a parameter retune tool, not an installer — it does not change binaries or solver backend.
• Backend or binary upgrade (one-result ↔ continuous, byron-solve2 sha bumps): use /dl/install.sh (clean install / re-install with current default pins) or /dl/apply-continuous.sh (legacy upgrade helper that swaps in .continuous binaries on top of an existing install). Which one depends on rollout stage: post-Phase 2e, install.sh ships continuous-capable binaries by default, so re-running it is the canonical upgrade path.

Running the wrong tool on a platform doesn't silently work — the scripts refuse cross-platform invocations: retune-cuda.sh refuses on macOS with a pointer at retune-mac.sh, and retune-mac.sh only runs from a Darwin shell. apply-continuous.sh validates the rig's existing cmdline and refuses if Step-B flagship knobs aren't present.

REPORTED RATE vs ACCEPTED MATMUL/s

ACCEPTED MATMUL/s is share-derived: your_share_rate × (2^256 / share_target). It's pool-verified (the pool recomputes every accepted share's digest from the nonce) and is the payout-trusted contribution metric. Goes to 0 during a single rig's normal share gap (because share_rate is a 5-min EMA and short-tailed at small share counts).

REPORTED RATE is whatever the rig's solver says it's doing — raw nonces examined per second, EMA-smoothed. The pool cannot verify this value. Units depend on the solver (nonce/s for byron-solve and byron-solve2; unknown/s for btx-gbt-solve or older clients). NEVER used for payouts — it's a health indicator only.

Why shares can reject

See the reject-class breakdown under Troubleshooting. Tl;dr: the dominant reject class on this pool today is stale shares — the rig submitted work for a block that's already been superseded. Almost always caused by either GPU contention (something else is sharing your GPU) or network jitter (notify→cancel→submit round-trip is too slow to keep up with the chain).

Why did my GPU briefly show 0%?

Short 0% dips that recover on their own (within ~20 s) are normal — it's the self-heal watchdog. → see Troubleshooting → GPU 0% self-heal for the full explanation.

Why is my "owed" so high?

OWED and PAID are for your WHOLE WALLET — the sum of every worker mining to your payout address — while the PROJECTION below them is for this rig only. One wallet can power many rigs, so on a shared address the wallet-level owed/paid will look much larger than a single rig's projection. On the dashboard's #/myrig view use the "show combined for all N workers" toggle to make the projection match the wallet scope.

Where do I see this rig's earnings and payout history?

Three places: the menu's [P] Payouts screen (earnings + payout history for this rig), the always-on local [W] cockpit (http://127.0.0.1:476xx, loopback-only), and the public dashboard's #/myrig view.

I pressed [Q] — did I stop mining?

No. [Q] only closes the menu; the miner keeps running. Re-open the menu from the local saved copy without the install URL: Linux bash ~/.byron/byron.sh, Mac bash ~/.byron/byron-mac.sh, Windows (PowerShell) & "$env:USERPROFILE\.byron\byron.ps1".

What is the [W] cockpit?

An always-on local, loopback-only dashboard for this rig (http://127.0.0.1:476xx). → see Troubleshooting → Local [W] cockpit for details.

How do updates work?

Rigs auto-update hourly; force one via menu [1] Install / Update. Upgrades are a ~few-second blip and auto-reverting. → see Troubleshooting → How updating works for details.

What is the welcome splash?

A brief lighthouse welcome screen the menu shows on launch. Suppress it with BYRON_NO_SPLASH=1 (or -NoSplash on Windows).

What clean jobs / cancels mean

When a new BTX block is found anywhere on the network, the pool detects it on its next 10s poll and sends every connected miner a mining.notify with clean_jobs=true. Your solver should immediately cancel its current work and start on the new job. Any shares still in flight for the old job will be rejected as stale.

BTX target block time is ~2 min, so clean jobs arrive every ~2 min on average. The pool also sends keepalive clean_jobs=false notifies every ~45s to surface dead connections.

What continuous mode does

The pool's solver (byron-solve2) can run in two modes: one-result (default, the legacy path) and continuous (Phase 2c v2+, behind --solver-backend continuous).

In one-result mode the solver spawns a fresh process for every share slice. That has per-spawn overhead and GPU warmup cost on each cycle. In continuous mode the solver runs as a long-lived daemon, accepting jobs over stdin and emitting shares + progress events over stdout. No per-share spawn cost; smoother throughput; the share-rate EMA reads steadier.

Continuous mode requires a continuous-capable byron-miner + byron-solve2 (the current golden pins on /dl/ — check /dl/SHA256SUMS for the exact shas; do not rely on a sha quoted here) and the byron-miner's ContinuousDaemon adapter. The Mac solver (byron-solve) does NOT have a continuous arm yet — macOS rigs always run one-result. Linux/CUDA rigs get continuous by default from a fresh install.sh (Phase 2e); older installs can opt in via apply-continuous.sh.

install.sh vs apply-continuous.sh

/dl/install.sh is the bootstrap installer. Downloads binaries to the rig's current directory, runs the platform's join-pool*.sh launcher, brings up Tailscale via a Headscale preauth key, and starts the miner under whatever supervisor pattern is appropriate (Runpod supervise.sh, macOS launchd, etc.). This is what every new rig runs.

As of Phase 2e, install.sh installs continuous-capable binaries by default on CUDA rigs — so for an existing rig the canonical upgrade path is simply to re-run install.sh (it pulls the current golden pins from /dl/SHA256SUMS). The legacy /dl/apply-continuous.sh helper still exists for older installs: run on top of an install.sh-installed rig, it swaps in the .continuous binaries (sha-verified), preserves your BTX_MATMUL_* env, and relaunches with --solver-backend continuous appended, generating a one-line rollback recipe next to the binary.

(Historically install.sh shipped one-result binaries and apply-continuous.sh was the only path to continuous; Phase 2e folded continuous into the default install, so the second step is no longer required for fresh installs.)

Intro

This page lists operator-run commands and source-backed tuning knobs only. The dashboard does not execute anything on your behalf — every command below is a manual copy-paste. Knob defaults and platform profiles below are read directly from scripts/join-pool.sh, scripts/join-pool-mac.sh, scripts/retune-mac.sh, scripts/apply-continuous.sh, byron-miner/src/cli.rs, byron-miner/src/solver.rs and byron-solve/byron-solve2.cpp — not guessed.

Always inspect scripts before running. Pipe through less first; pipe through bash once you've read it.

Change one knob at a time, watch the rig for 5–10 min, decide keep or revert. Multi-knob changes confound the result.

Some changes are canary / non-persistent and may revert on container restart or full re-install.

Quick Action — Mac Retune

Purpose: flip a single Metal-tuning knob on a running Mac rig and restart, without re-running the full installer.

Script: /dl/retune-mac.sh

Inspect command:

curl -fsS https://btxbyronbay.com/dl/retune-mac.sh | less

Example apply command:

curl -fsS https://btxbyronbay.com/dl/retune-mac.sh | bash -s -- --gpu-inputs 1

Supported knobs: --gpu-inputs, --solver-threads, --batch-size, --prepare-workers, --slice-seconds. Single-variable contract — to change multiple knobs, run once per knob.

Persistence: the running tmux session and ~/byron-miner.log get the new value immediately; on Mac reboot the LaunchAgent or operator-installed start path may revert. Re-run after reboot if needed.

Use when: a Mac rig's REPORTED RATE / ACCEPTED MATMUL/s looks low for its chip class, or operator wants to A/B a single value.

Quick Action — NVIDIA Continuous Canary

Purpose: switch one NVIDIA rig from the default one-result solver path to the Phase 2c continuous path (long-lived solver session, streamed shares, stdin-cancel).

Script: /dl/apply-continuous.sh

Inspect command:

curl -fsS https://btxbyronbay.com/dl/apply-continuous.sh | less

Apply command:

curl -fsS https://btxbyronbay.com/dl/apply-continuous.sh | bash

Refuses to run unless the current cmdline already has the Step-B flagship knobs:

--solver-backend continuous
--batch-size 512
--prepare-workers 16
--solver-threads 8
--gpu-inputs 1

Ampere-workstation (sm_86 / A4500) rigs use a smaller profile by default and need a manual relaunch with the flagship knobs first — this script will refuse otherwise.

Persistence: this canary helper predates Phase 2e. As of Phase 2e, /dl/install.sh ships continuous-capable binaries by default on CUDA rigs, so for a fresh/re-run install you no longer need this step — re-running install.sh is the canonical path. Use this helper only to flip an older install in place; it remains canary / non-persistent across a container rebuild that re-runs the old launch path, so re-apply after such a rebuild.

Warning: run one rig at a time; paste back the stage-complete output block and a tail -30 of the rig's miner log so we can confirm a clean start.

Quick Action — CUDA Retune

Linux/NVIDIA CUDA rigs only. Tunes an already-installed CUDA rig's launch parameters without reinstalling or changing binaries. retune-cuda.sh is a parameter retune tool, not an installer — it does not download binaries, does not change the solver backend, and does not make btx-gbt-solve continuous. It only changes supported knobs that are already present in the current byron-miner command line.

Do not run on Mac/Metal rigs. Use /dl/retune-mac.sh for Apple Silicon.

Script: /dl/retune-cuda.sh

Inspect command:

curl -fsSL https://btxbyronbay.com/dl/retune-cuda.sh | less

Help command:

curl -fsSL https://btxbyronbay.com/dl/retune-cuda.sh | bash -s -- --help

Dry-run example:

curl -fsSL https://btxbyronbay.com/dl/retune-cuda.sh | bash -s -- --dry-run --prepare-workers 16

Apply example:

curl -fsSL https://btxbyronbay.com/dl/retune-cuda.sh | bash -s -- --prepare-workers 16

Supported knobs (one per invocation):

--batch-size
--prepare-workers
--solver-threads
--gpu-inputs
--slice-seconds
--slice-nonces    (only if already present in the current cmdline)

About --slice-nonces: Only tunable if --slice-nonces is already present in the current command line; most installs use the miner default and omit it, in which case the script refuses with "not present in current cmdline — can't tune what isn't set already." To add the flag for the first time, re-run join-pool.sh with it explicitly.

Persistence: auto-detects layout. On Runpod-style rigs (active supervise.sh) it edits miner.env and lets supervise.sh respawn the miner; on vanilla install.sh rigs (~/byron/ + tmux) it edits tune.conf and relaunches the tmux session. Generates timestamped rollback-retune-cuda-<TS>.sh next to the rig directory on every apply — never overwrites a prior rollback.

Warnings:

• Run on the target CUDA rig only. Use --dry-run first.
• One knob per invocation. Single-knob contract.
• Does NOT change binaries. Does NOT change the solver backend — for backend or binary-aware changes use /dl/apply-continuous.sh instead. Specifically: this script does not make btx-gbt-solve continuous; btx-gbt-solve has no --continuous mode and the script refuses --solver-backend regardless of which solver basename is in use.
• Do NOT run on Mac/Metal rigs — use /dl/retune-mac.sh for Apple Silicon. This script is not for Mac/Metal.
• Watch ACCEPT RATE, REJECTS, REPORTED RATE, ACCEPTED MATMUL/s, GPU%, and POOL HEALTH on the dashboard for ~5 min after applying.

Source: scripts/join-pool-mac.sh (profile selection, env exports), scripts/retune-mac.sh (single-knob edit), byron-miner/src/cli.rs (CLI arg parser).

Source: scripts/join-pool.sh (profile selection, tune.conf), scripts/apply-continuous.sh (continuous canary), scripts/rig-boot/supervise.sh (miner.env re-source loop), byron-miner/src/cli.rs (CLI arg parser), byron-miner/src/solver.rs (env forwarding), byron-solve/byron-solve2.cpp (env auto-set in main()).

Encoded profiles come directly from the installer scripts. "Constrained CPU + high-end GPU" is operator-observed only and should be tested rig-by-rig.

Rollback Notes

/dl/apply-continuous.sh generates local rollback scripts next to the rig install path. The exact rollback path is printed by the script at the end of the apply output (e.g. /workspace/byron-pool-rig/rollback-continuous.sh on Runpod-style rigs, or wherever the rig dir is). Use the path the script gives you — do not guess.

/dl/retune-mac.sh: on a successful run it prints the exact one-liner to revert (the previous flag value). On failure (solver did not signal ready within 20 s) it prints the same revert one-liner and exits non-zero.

/dl/retune-cuda.sh: on each apply it backs up the persistence file (miner.env on Runpod or tune.conf on vanilla) with a timestamped suffix and writes rollback-retune-cuda-<TS>.sh next to the rig directory — never overwrites prior rollbacks. The exact rollback path is printed at the end of every successful run AND at the start of every failure path. On smoke-check failure (no solver daemon ready within 30 s) the script auto-invokes its own rollback before exiting non-zero.

What each knob means

--gpu-inputs — 0|1 toggle for GPU-vs-CPU solver input preparation. 0 = CPU prepares (the Pascal+ correctness fix; in-CPU input streams). 1 = GPU prepares (in-flight GPU input streams/buffers; the Ada/Blackwell/sm_86/M4 Max performance path). Wrong setting per arch costs 2–5× throughput.

--batch-size — solver matmul batch size (nonces per kernel launch). Bigger = better GPU saturation up to VRAM limits.

--prepare-workers — CPU-side workers preparing solver input batches. Installer clamps to physical cores (oversubscribing thrashes the CPU and starves the GPU).

--solver-threads — solver worker threads inside the solver binary. Mac: hard cap at 6 (Metal hang risk above). CUDA: 8 default with one exception (sm_86 A4500-proven at 4).

--slice-seconds — solver slice length in seconds. Higher = better GPU saturation; lower = fewer stale shares on clean-job boundaries.

--slice-nonces — hard ceiling on nonces per slice. Safety cap; slice-seconds usually binds first.

--watchdog-secs (default 20, ON) — continuous-solver self-heal. If the solver signals ready but makes no GPU progress within this window (the CUDA stop-then-relaunch swap-race / 0%-GPU-but-alive case), the miner kills + respawns it. Continuous mode only; one-result and Mac/Metal rigs have no watchdog arm. 0 disables (don't, in production).

--watchdog-max-retries (default 4) — max quick watchdog respawns before a ~30 s cooldown, so a genuinely unavailable GPU doesn't thrash.

--solver-backend continuous — switches the solver driver from one-result (the default) to a long-lived solver session that streams shares and accepts stdin-cancel (Phase 2c). Requires a continuous-capable byron-solve2 binary.

BTX_MATMUL_PIPELINE_ASYNC=1 (env, auto) — async pipeline overlapping CPU prep with the matmul kernel.

BTX_MATMUL_PREPARE_PREFETCH_DEPTH=8 (env, auto) — depth of the CPU→GPU input queue.

BTX_MATMUL_METAL_POOL_SLOTS (env, Mac only) — Metal command-buffer parallelism inside btx core.

BTX_MATMUL_CPU_CONFIRM=0 (env, Mac) — disable in-solver CPU re-verification (the pool re-verifies every share).

BTX_MINER_HEADER_TIME_REFRESH_ATTEMPTS=4294967295 (env, auto-set by byron-solve2) — disables internal nTime refresh. CRITICAL: without it, every share rejects because nTime drifts before pool re-verification.

Safety notes

Do not run these from the dashboard host unless you are intentionally tuning that host.

Run commands on the target rig only. Inspect first, run second.

Change one rig at a time. Change one knob at a time.

Watch ACCEPT RATE, REJECTS, ACCEPTED MATMUL/s, REPORTED RATE, GPU% (avg + raw) and POOL HEALTH after every change.

Higher REPORTED RATE is not useful if ACCEPT RATE drops — the pool only credits accepted shares.

Do NOT run Mac retune commands on CUDA rigs (they pkill byron-solve not byron-solve2, and assume a tmux launch pattern).

Do NOT run CUDA canary commands on Mac rigs (they verify CUDA-specific cmdline knobs and download Linux-x86_64 binaries).

These tools do not change payouts directly; they only affect rig behavior.