argfa/bc3-gpu repository overview

⁠ArgfaMining BC3 (BitcoinIII) GPU Miner — AURORA-FUSION

Official GPU miner for BitcoinIII (BC3) — BC3Hash since block 64,360, and SHA3-256t before it — built for the ArgfaMining⁠ pool. Native multi-GPU: one process drives every supported card in the rig (single worker, summed hashrate).

⁠What's new in 5.8.0 — faster on NVIDIA, and much less CPU

More hashrate on NVIDIA, measured against 5.7.0 on the same rented card (Clore.ai, 13–14 Oct 2026), alternating five-minute runs of each version, with zero rejected shares:

The RTX 4090 ran at a 375 W power limit.

• Much lower CPU use. 5.7.0 kept one CPU core at 100 % for every GPU while it waited for the card; 5.8.0 uses about 5 % of a core per GPU, with the same hashrate. Rigs with many cards and a small CPU gain the most.
• Cards with 6 GB of memory keep the fastest setup with about 270 MB less free memory than before.
• MODE is no longer case sensitive: PROP, Prop and prop all mine PROP. An unknown mode now stops the miner with an error (exit code 2) instead of silently mining SOLO.
• On an NVIDIA GPU from a generation newer than this build knows, the miner says so and asks you to update, instead of failing with a CUDA error.
• The image includes LICENSE.txt and THIRD-PARTY-NOTICES.txt.

⁠Benchmarks — BC3Hash, 1-hour average (5.7.0)

Measured with the 5.7.0 image on GPUs rented on Clore.ai, one full hour per card. The hashrate is the miner's own 1-hour average, with zero rejected shares on every card.

The RTX 4080, 4070 and 3080 ran on a host that locks the core clock (2,205 / 1,455 MHz), so stock cards should do a bit more. The RTX 5070 is our own rig at a 120 % power limit. Both benchmark cards, this one and v5.8.0 against v5.7.0, are at https://argfamining.com/bc3_how_to_mine.html#benchmarks⁠.

⁠What came in 5.7.0 — a full report in the container log

docker logs now shows what the miner is doing, one line per event, with the time:

• every new job with its block height and proof of work, every share with the GPU that found it and how many milliseconds the pool took to answer, every rejected share with the reason the pool gave, the switch to BC3Hash at the fork block, and every block found with a link to it in the explorer;
• every 30 seconds, a table per GPU: hashrate, power draw, efficiency, fan, temperature, core and memory clocks, accepted shares, rejected shares and hardware errors. Under it: the total, the 1 min / 15 min / 1 h averages and about how often to expect a share.

The technical debug log no longer fills the output. It is written inside the container (two files of 20 MB at most). If you report a problem, run with -e ARGFA_VERBOSE=1 so it shows up in docker logs too.

Also in 5.7.0: shares go out to the pool as soon as they are found, shares for a block that already ended are no longer sent (the pool would reject them as stale), and after a dropped connection the reconnect wait starts again at one second.

⁠What came in 5.6.0 — ready for the BC3Hash hard fork

At block 64,360 BitcoinIII changes its proof of work from SHA3-256t to BC3Hash.

• This image mines both and switches by itself at the fork block: it reads which one each job needs, so there is nothing to change and no restart.
• 5.5.2 and older only know SHA3-256t. From block 64,360 on, the pool rejects every share they send: pull 5.6.0 (or latest) before the fork.
• BC3Hash is a much heavier hash: expect about 1 MH/s on an RTX 5070 instead of hundreds of MH/s. That is normal — the whole network moves to the same scale.
• Before mining its first BC3Hash job the miner checks the GPU against the CPU on known results, and stops with a message instead of sending shares the pool would reject.
• Every share now reaches the pool. When the GPU found more than one share in the same batch, older versions sent only one; on SHA3-256t that lost up to about one share in eight.
• The base moves to ubuntu:26.04.

⁠What came in 5.5.2 — a failed start now tells you what is missing

No kernel or engine changes: same hashrate as 5.5.0. What changed is everything around a start that does not work.

• An unknown REGION is refused instead of quietly falling back to usa — and the city name works now (frankfurt, mumbai, virginia).
• When no GPU can be used, the log prints the NVIDIA driver you have and the one this image needs (R580 — it ships CUDA 13). Before, it listed your cards and then said no GPU detected with nothing else.
• Datacenter cards no longer report themselves as PTX fallback while running a native kernel.

⁠What came in 5.5.0 — datacenter GPUs now mine

The image ships native code for eight NVIDIA architectures instead of four. If you rent GPUs, this is the release that matters: the datacenter cards on vast.ai, RunPod and octa.space were detected before but could not mine — the binary had no kernel for them.

Newly supported:

Already supported, unchanged: RTX 20xx / GTX 16xx / T4 (75), RTX 30xx (86), RTX 40xx (89), RTX 50xx (120).

These are natively compiled kernels, not JIT — full speed from the first second, no warm-up compile. Mining behaviour is unchanged on cards that already worked: same kernel, same hashes, same speed.

⁠What came in 5.3.0 — your address is checked before you mine

The miner verifies the checksum of your payout address, not just its shape, and refuses to start if a single character is wrong. A mistyped address still looks perfectly valid (right prefix, right length) but nobody can pay it: your shares count, your hashrate shows on the dashboard, and the reward never arrives.

Check any address without starting the miner:

docker run --rm argfa/bc3-gpu:latest --check-address <your address>

It prints the address type and exits 0 when valid.

Also fixed in 5.3.0: duplicate shares that the pool rejected while auto-tune was stepping through intensity levels.

⁠What came in 5.2.0 — mixed NVIDIA+AMD rigs

The miner enumerates CUDA and OpenCL GPUs in a single unified list and runs CUDA + OpenCL contexts in the same process: rigs mixing NVIDIA and AMD cards mine with all of them (per-backend boot self-test; iGPUs are listed but deselected by default; true AMD multi-GPU). Inside Docker, --gpus injects the NVIDIA driver only, so the mixed-rig case applies to the native Linux/Windows builds for now (ROCm base image pending).

⁠Quick start

docker run --rm --gpus all \
  -e WALLET=your_bc3_address \
  -e WORKER=rig1 \
  -e MODE=prop \
  -e REGION=usa \
  argfa/bc3-gpu:latest

⁠Renting on a platform that builds the run command for you

On clore.ai, Salad, TensorDock and similar, you pick an image and fill a form — you never write the docker run, so there is no --gpus all to add. GPU access there is driven by environment variables, and the two below are the ones that matter. Set them next to WALLET / WORKER / MODE / REGION:

NVIDIA_VISIBLE_DEVICES=all
NVIDIA_DRIVER_CAPABILITIES=all

The image already declares both, but these platforms build their own run command and the image's values do not always survive it. Setting them explicitly costs nothing. Use all for the capabilities: clore.ai's form drops commas, so compute,utility arrives as computeutility and the driver is not injected.

MODE is not case sensitive since 5.8.0 (5.7.0 read PROP in capitals as SOLO).

On clore.ai, if you tick SSH auto-install entrypoint, Clore replaces the image's start-up and the miner does not start by itself: log in and run WALLET=… WORKER=… MODE=prop REGION=usa /opt/entrypoint.sh inside screen.

If the miner exits immediately with exit 127, that is the NVIDIA driver not reaching the container — libcuda.so.1 and libnvidia-ml.so.1 come from the host and are not inside the image. Confirm it in one command:

docker run --rm --entrypoint nvidia-smi argfa/bc3-gpu:latest

If that fails inside the container the problem is the GPU passthrough, not the miner.

⁠Configuration (environment variables)

Regions: latam (Venezuela) · usa (Virginia) · eu (Frankfurt) · in (Mumbai, India).

BC3 accepts all five address formats: 1… (P2PKH), 3… (P2SH), bc1q… (P2WPKH/P2WSH), bc1p… (P2TR).

⁠Multi-GPU

By default the miner uses all supported GPUs. Pin specific cards with -e DEVICES=0,1. Any extra arguments after the image name pass straight to the miner.

⁠Requirements (host)

• NVIDIA driver R580 or newer (the minimum for CUDA 13, which this image uses) + nvidia-container-toolkit. Both are pre-installed on vast.ai / RunPod / octa.space, but check the driver on the offer before you rent. On platforms where you don't write the docker run (clore.ai, Salad, TensorDock), see the note above the configuration table.
• GPU: NVIDIA sm_75 or newer — Turing, Ampere (incl. A100), Ada, Hopper (H100/H200) and Blackwell (RTX 50xx and B100/B200/B300). AMD via OpenCL (mixed NVIDIA+AMD rigs supported by the miner binary; in Docker the AMD runtime needs a ROCm base — pending).
• Pre-Turing cards (GTX 10xx and older) are not supported: NVIDIA removed them from the CUDA 13 toolkit this miner is built with, and that goes for all our packages, HiveOS included.
• Small ubuntu:26.04 base (~235 MB); the CUDA runtime (libcudart.so.13) ships inside the image and the driver is injected at runtime by --gpus.

⁠Validation

On start it prints the kernel self-test per backend — it must say PASS. In the [mining] lines, verify_fail must stay 0 and accepted shares (acc) should climb; the table above each one should show no rejected shares (R) or hardware errors (HW).

⁠Notes

• Tags: 5.8.0 (pinned) · latest.
• Pool-locked: this image mines exclusively to ArgfaMining; the region selects the endpoint.

Support: https://discord.gg/nZTu2QC2YC⁠