Skip to content

Mining pool basics

Bitcoin Gold uses Equihash-BTG (N=144, K=5, personalization BgoldPoW), a memory-intensive proof-of-work algorithm. This page covers the operating concepts of a Bitcoin Gold mining pool — the part that interfaces with bgoldd and the part that talks to miners over Stratum.

This is not a guide to running a profitable pool. It is a guide to the moving parts so you can decide whether to join an existing pool, run a small private one, or contribute upstream.

Who this is for

You want to understand how a Bitcoin Gold pool:

  • Receives getblocktemplate from a full node.
  • Distributes work to miners over Stratum.
  • Tracks shares and computes rewards.
  • Submits valid blocks back to bgoldd.

What you'll learn

  • The full request flow from miner to blockchain.
  • The bgoldd RPCs a pool needs.
  • How PPLNS / PPS / SOLO differ in payout.
  • Why a pool needs --zmqpubhashblock.

Concepts

Equihash-BTG mining parameters

Parameter Value
Algorithm Equihash-BTG (Zcash-derived)
N, K 144, 5
Personalization BgoldPoW
Solution size 100 bytes
Memory per thread ~2.5 GB
Block time target 10 minutes (600 s)
Difficulty adjustment Zawy's LWMA, 45-block window

You can verify these against your own bgoldd:

bgold-cli getmininginfo
bgold-cli getblocktemplate '{"rules":["segwit"]}' | jq '.coinbasetxn,.target, .mintime'

Stratum protocol

Bitcoin Gold pools speak standard Stratum v1 (the same as BTC and most Equihash coins). The basics:

Method Direction Purpose
mining.subscribe miner → pool Login, get extranonce1
mining.authorize miner → pool Authenticate with walletaddress.workername
mining.notify pool → miner New job: job_id, prevhash, coinb1, coinb2, merkle_branch, version, nbits, ntime, clean_jobs
mining.submit miner → pool Submit share: worker_name, job_id, extranon ce2, ntime, nonce, solution
mining.set_difficulty pool → miner Server-set per-worker difficulty

The wallet address embedded in the mining.authorize call is the payout address for that miner. Pools credit all rewards to that address (minus fees).

Payout schemes

Scheme Risk to miner Risk to pool Notes
PPS (Pay Per Share) None — every accepted share has a fixed value Pool absorbs variance Higher pool fee (~3 %).
PPLNS (Pay Per Last N Shares) Reward varies with pool luck Pool does not pre-fund share payouts Fees and share window are set by the operator.
SOLO Miner keeps full block reward No pool, just the daemon Only worth it for very large hashrate.

Bitcoin Gold community pools mostly use PPLNS.

The role of a full node

A pool is a daemon wrapper. The chain itself is held by one or more bgoldd instances. The pool:

  1. Calls getblocktemplate on each new tip (ZMQ hashblock triggers a refresh).
  2. Constructs a Stratum job from the template, replacing the coinbase output with the miner's address.
  3. Distributes the job to subscribed miners.
  4. Collects mining.submit shares, validates the Equihash solution locally (cheap), and credits shares.
  5. When a share is also a valid block (meets network difficulty), submits it to bgoldd via submitblock.

1. The bgoldd side

A pool needs a bgoldd that exposes:

  • RPC for getblocktemplate, submitblock, getblock, getblockhash.
  • ZMQ for hashblock (so the pool re-templates immediately on a new block, instead of polling).

Add to /var/lib/bitcoingold/.bitcoingold/bitcoingold.conf:

# Required for any pool backend
server=1
txindex=1
rpcuser=pool
rpcpassword=STRONG_PASSWORD
rpcbind=127.0.0.1
rpcallowip=127.0.0.1

# Re-template on new block
zmqpubhashblock=tcp://127.0.0.1:38335

# Pool traffic (don't cap upload — helps the network)
maxuploadtarget=0

A small set of submitblock-related limits the pool will rely on:

# Maximum number of blocks the pool can submit in parallel
# (default is fine; raise if you have many workers)
bgold-cli submitblock <hex>

2. Reference pool software

A few options for actually running the pool backend:

Software Language Notes
node-stratum-pool Node.js Used by many small BTC-fork pools. Requires manual patches for Bitcoin Gold.
Miningcore C# Modern, multi-coin. Has Bitcoin Gold support upstream.
MPOS PHP Front-end only; needs a stratum backend.

For v1, the simplest path is Miningcore — it has Bitcoin Gold support out of the box (configurable coin definitions), a real admin UI, and supports Stratum + Stratum-WS.

3. Miningcore for Bitcoin Gold (sketch)

# Build (after cloning)
git clone https://github.com/coinfoundry/miningcore.git
cd miningcore
docker build -t miningcore .

Miningcore's schema changes between releases, so a static copy-and-paste coins.json is unsafe. Start from the schema and examples shipped with the exact Miningcore revision you pin. At minimum, verify these constants against BTCGPU/BTCGPU and a synchronized node:

Field Mainnet value
Symbol BTG
Algorithm equihash-btg
Equihash parameters N=144, K=5
Personalization BgoldPoW
P2P port 8338
RPC port 8332
Equihash-BTG activation height 536200
Genesis hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Do not hard-code the current block subsidy or a payout confirmation threshold from an example. Query chain state through the daemon and choose payout maturity according to your own reorganization and operational-risk policy.

Genesis block hash

Bitcoin Gold mainnet shares Bitcoin's history before the fork, including genesis hash 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. The hash beginning 00000000e078... belongs to Bitcoin Gold testnet and must not be used for mainnet.

4. What to expose to miners

Your pool's Stratum endpoint. For Bitcoin Gold, common choices:

Address Use
stratum+tcp://btg.example.com:3333 Stratum v1 (universal)
stratum+ssl://btg.example.com:3334 Stratum v1 over TLS (more secure)
stratum+tcp://btg.example.com:3335 Stratum v1 with fixed difficulty

Port 3333 is a common Stratum port, but the actual port is up to the pool operator.

5. Worker setup

A miner connects with:

URL:       stratum+tcp://btg.example.com:3333
Username:  GYf8nyo1c8oWsHzbvL1fD3Ckgg68UzBi5J.worker1
Password:  x

The part before the . is the payout address (a Bitcoin Gold P2PKH or bech32 address). The pool credits all shares to that address. The part after the . is the worker name (for the miner's own stats).

If you're running your own miner to your own pool:

# Example with EWBF (popular Equihash miner; legacy but stable)
./ewbf-equihash-btg \
  --algo 144_5 \
  --pers BgoldPoW \
  --server btg.example.com \
  --port 3333 \
  --user GYf8nyo1c8oWsHzbvL1fD3Ckgg68UzBi5J.worker1 \
  --pass x

Verify current Equihash-BTG support in your chosen miner's official documentation before use.

6. Verifying the pool is healthy

# Does the pool have a fresh block template?
stratum-cli ping btg.example.com:3333

# Stratum subscribe (raw)
echo '{"id":1,"method":"mining.subscribe","params":[]}' | \
  timeout 5 nc -q1 btg.example.com 3333
# Expect: extranonce1, extranonce2_size

# Stratum authorize
echo '{"id":2,"method":"mining.authorize","params":["GYf8nyo1c8oWsHzbvL1fD3Ckgg68UzBi5J.w","x"]}' | \
  timeout 5 nc -q1 btg.example.com 3333
# Expect: {"id":2,"result":true,"error":null}

A healthy pool accepts both calls in well under a second and immediately pushes mining.notify to subscribed clients.

7. Operations

Payouts

  • PPLNS pool → cron-driven payout script that runs every N hours.
  • PPS pool → immediate credit at the time of share acceptance.
  • SOLO → only the block-finding miner gets paid; the pool does nothing.

For PPLNS, the payout address is the miner's mining.authorize user. The pool has its own coinbase script that takes the pool fee from each block reward.

Fee structure

Tier Typical fee
PPS 2–4 %
PPLNS 0.5–1 %
SOLO 0 % (but you keep the whole block reward yourself)

Monitoring

Watch:

  • Stale share rate — should be <2 %. Higher means the pool is lagging on getblocktemplate refreshes.
  • Reject rate — should be <1 %. Higher means stale jobs or bugs in the share validator.
  • Pool hashrate — 5-minute EMA. Drops signal problems.
  • Block-finding rate — actual blocks / expected blocks. Tracks luck.

Troubleshooting

"Invalid solution" rejection storm

Usually means a bug in the share validator or a configuration mismatch. Check that equihashParameters: "144,5" and personalization: "BgoldPoW" match the network exactly.

"Stratum subscribe" returns null extranonce

The pool is misconfigured. Restart the pool backend.

"Connection refused" from your own pool

ss -lntp | grep 3333
journalctl -u miningcore -f

Blocks not being submitted

submitblock is failing. Check bgoldd's debug.log:

tail -f /var/log/bitcoingold.log | grep -i submitblock

Common cause: the pool is submitting a block whose coinbase doesn't validate under Bitcoin Gold's rules (e.g. a wrong address version byte). Compare the pool's coinbase script to a known-good block.

What to do next

  • Stand up a public Bitcoin Gold pool with Miningcore + a nginx + a front-end like Miningcore-ui (or build your own).
  • Expose stats: per-worker hashrate, payout history, network difficulty — see the Blockbook / ElectrumX patterns for inspiration.
  • Run an ElectrumX + Blockbook stack alongside the pool so users can check their balance without trusting you.
  • Harden the pool host following Hardening.
  • Read the Bitcoin Gold wiki Technical-Spec to understand the consensus rules your pool must respect.

Source / further reading