Build your own blocks.

On this path you do not point a miner at us. You run a Bitcoin Knots node and a DATUM gateway on a machine of your own; your node decides which transactions go into the block, and the pool answers one question only — who gets paid what. This is the way we would rather you mined, and it is the one that still pays after Bitcoin Knots stops paying for blocks the miner did not build.

Pool fee: 1 %; the same on plain stratum
Gateway port: 28915; all four regions
Prime ID: 4243; how explorers name you
Smallest payout: 10,000 sat; below that, carried on
Disk for the node: ~40 GB; pruned, not the full chain

Read this first Your node must be Bitcoin Knots 29.4.2 or newer. An older build does not know the long coinbase maturity rule and will happily put a premature coinbase spend into a template — and every block built on that template is rejected by the network. You would not just lose your own block; the round is lost for every miner in the pool. Fifteen blocks have already been lost this way on this chain, none of them ours. There is no way to make an old node safe here, so check the version before anything else.

Why this is the path we recommend.

Not because it is harder. Because of who holds the template.

On our ordinary stratum ports we build the block template for you. That works, it pays the same way, and for a single miner on a desk it is the sensible choice. But it means we pick the transactions, and you take our selection on trust — including whatever policy we happen to run that week. A pool that builds every template is a pool that could, in principle, be leaned on.

With your own gateway the template is yours. Your node's relay policy, your mempool, your fee floor. We never see the block before it exists, and we cannot censor what we do not build. All the pool contributes is the payout split — the list of addresses and amounts your gateway writes into the coinbase. The fee is 1 %, the same as plain stratum pays today.

The honest cost is that you run a node. It wants about 40 GB, it wants to stay switched on, and the first sync takes a day or three. After that it looks after itself. How the pool pays is the same on both paths — straight from the block's coinbase, no balance, nothing to withdraw.

What you need before you start.

A machine that stays on: Any 64-bit Linux box (x86-64 or ARM64), a Mac, or Windows. Two cores is plenty. A Raspberry Pi 5 with an SSD is enough; an SD card is not.
About 40 GB free: The chain, pruned. The UTXO set alone is 11 GB today and only grows; the rest is your prune budget and headroom for the initial sync.
8 GB RAM, comfortably: 4 GB works with a smaller dbcache. It only matters during the first sync.
One to three days: For that first sync. You can set everything else up while it runs, but the gateway serves no work until the node has caught up.
Your BTCB2 address: A native SegWit address (bc1q…) from a wallet you control. The pool writes it straight into the block — there is no account here and nothing to register.

Six steps.

Commands are for Linux. Mac and Windows differ only in how you fetch the two downloads.

01Install Bitcoin Knots

This is the client that knows the BLAKE2b chain. Take it from the project, verify the checksum, and do not substitute a Bitcoin Core build — Core does not have the fork.

V=29.4.2.knots20260508
cd /tmp
curl -fsSLO https://bitcoinknots.org/files/29.x/$V/bitcoin-$V-x86_64-linux-gnu.tar.gz
curl -fsSLO https://bitcoinknots.org/files/29.x/$V/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS
sudo tar -xzf bitcoin-$V-x86_64-linux-gnu.tar.gz -C /opt
sudo ln -sf /opt/bitcoin-$V/bin/bitcoind  /usr/local/bin/bitcoind
sudo ln -sf /opt/bitcoin-$V/bin/bitcoin-cli /usr/local/bin/bitcoin-cli
bitcoind --version | head -1

On ARM64 swap x86_64 for aarch64. The last line must say 29.4.2 and mention Knots. If sha256sum does not print OK, stop and fetch the file again — a truncated download is the usual cause.

02Configure the node

Write this to ~/.bitcoin/bitcoin.conf. Generate the password instead of inventing one: openssl rand -hex 24.

~/.bitcoin/bitcoin.conf

server=1
rpcbind=127.0.0.1
rpcallowip=127.0.0.1
rpcuser=datum
rpcpassword=PASTE_THE_RANDOM_HEX_HERE

prune=10000
dbcache=2048

blockreservedweight=32000
blocknotify=curl -fsS -o /dev/null http://127.0.0.1:7152/NOTIFY

blockreservedweight=32000 is the setting nobody else documents, and leaving it out quietly costs your fellow miners money. Here is why. The pool hands your gateway a list of payout outputs — lately 160 to 250 of them. Those outputs have to fit in the coinbase, and the only room a template leaves for the coinbase is this reserve. The default is 8,000 weight units: about 40 outputs. Everything beyond that is simply dropped, its value falls to the pool's own address, and it has to be settled by hand afterwards. We run 32,000 on all four of our nodes — measured in production, that is room for 246 outputs instead of 153 — and nothing is lost. Raise it, do not lower it.

Some pools tell you to cap the whole block with blockmaxweight=740000 instead. That also leaves room, but it throws away the transaction fees that would have filled the rest of the block. Reserving is the cheaper knob.

The rest is ordinary. prune=10000 keeps 10 GB of blocks — nothing on this path needs old history, and txindex in particular is a waste of disk here. blocknotify is what makes your gateway switch to a new tip in under a second instead of waiting for its next poll; it points at the gateway you install in the next step. Then start the node and let it sync:

bitcoind -daemon
bitcoin-cli getblockchaininfo | grep -E 'blocks|headers|verificationprogress'

When verificationprogress reaches 1 you are done. Until then the gateway will start but serve no work, which is correct.

03Install the gateway

There is no compiler step. ratum-gateway ships as a single static binary of about 2.4 MB with no dependencies at all.

V=0.1.57
cd /tmp
curl -fsSLO https://github.com/iohzrd/ratum/releases/download/v$V/ratum-gateway-$V-x86_64-linux-musl.tar.gz
curl -fsSLO https://github.com/iohzrd/ratum/releases/download/v$V/ratum-gateway-$V-x86_64-linux-musl.tar.gz.sha256
sha256sum -c ratum-gateway-$V-x86_64-linux-musl.tar.gz.sha256
tar -xzf ratum-gateway-$V-x86_64-linux-musl.tar.gz
sudo install -m0755 ratum-gateway-$V-x86_64-linux-musl/ratum-gateway /usr/local/bin/
ratum-gateway --version

Releases also carry aarch64-linux-musl, x86_64-macos, aarch64-macos and x86_64-windows.zip. Version 0.1.57 is what we currently see working against our pool; if you prefer the C implementation, the CONVOY DATUM gateway reads the very same configuration file and we accept it too.

04Point the gateway at B2Pool

One file. Replace the two marked lines with your own address and a password of your choosing; everything else can stay exactly as it is.

gateway.json

{
  "bitcoind": {
    "rpcurl": "http://127.0.0.1:8332",
    "rpcuser": "datum",
    "rpcpassword": "THE_SAME_HEX_AS_IN_BITCOIN_CONF",
    "work_update_seconds": 40,
    "notify_fallback": true
  },
  "stratum": {
    "listen_addr": "0.0.0.0",
    "listen_port": 23334,
    "vardiff_min": 2048,
    "require_address_username": true
  },
  "mining": {
    "pool_address": "YOUR_OWN_bc1q_ADDRESS",
    "coinbase_tag_secondary": "your-name-here"
  },
  "api": {
    "listen_addr": "127.0.0.1",
    "listen_port": 7152,
    "admin_password": "PICK_SOMETHING"
  },
  "datum": {
    "pool_host": "de.b2pool.io",
    "pool_port": 28915,
    "pool_pubkey": "8ba1f7693d117620b1e5a46828f1cd187efe81114e9cee6a063bfbbe2f1b6cff0fc681d3c1ca7cb19c0e0dbddfbea65d5509e974e7f0000112dd07cba744a716",
    "pool_url": "https://b2pool.io",
    "pool_pass_workers": true,
    "pool_pass_full_users": true,
    "pooled_mining_only": true
  }
}

Pick the host with the lowest ping to you — de, hel, ord or hkg, all on .b2pool.io:28915. They are the same pool and the same ledger; only the distance differs. The dashboard measures the round trip from your own browser if you are unsure.

The public key pins the connection. A gateway handed the wrong one gets no session and serves no work, which is the point: nobody can quietly stand between you and the pool. Copy it exactly. You can leave the field empty to have it fetched automatically, but then you are trusting the first answer you get, so don't.

coinbase_tag_secondary is your name in the block. We set the primary tag ourselves — that is DATUM convention and it is how explorers attribute the block to the pool at all — but the second string is yours and we never overwrite it. It is what shows up on block explorers next to our name, and it is the reason your blocks read DATUM miners via B2Pool rather than just the pool.

Then start it:

ratum-gateway -c /etc/ratum/gateway.json

Once it works, give it a systemd unit so it comes back after a reboot. One note on pooled_mining_only: left at true, your miners go idle if the pool is unreachable. Set to false they keep mining, and any block found in that window pays 100 % to your own mining.pool_address instead of to the split. Both are defensible; the first is predictable, the second never stops hashing.

05Point your miners at the gateway

Your hardware now talks to your own machine, not to us. Use the gateway host's LAN address:

stratum+tcp://192.168.1.50:23334

Username: bc1q…youraddress.rig-01 — your payout address, optionally a dot and a worker name
Password: anything, it is not checked
Smallest difficulty: 2,048. The pool credits nothing below that, so leave vardiff_min where it is

The part before the first dot has to be a real address on this chain — the pool credits work to exactly that string, and anything else comes back as BadUsername. Which address gets paid depends on two gateway settings:

Gateway setting	What the pool receives	Who gets paid
pool_pass_full_users: true	each miner's own username, unchanged	each miner's own address, separately
pool_pass_workers: true pool_pass_full_users: false	your mining.pool_address, then a dot and the worker name	you — the worker name is only a label

The configuration above uses the first, so a gateway can sit in front of several people's machines and each is paid to their own address. If every miner behind it is yours, the second is tidier.

pool_pass_full_users wins. With it on, pool_pass_workers is ignored, so setting both — as the sample does — gives you the first row and not a blend of the two. It also decides what the pool page can show you, because the pool only ever sees the username your miner sent. A miner that authenticates as a bare address, with nothing after it, arrives as a single identity: one total, no worker list, no miner count. Give each miner <address>.<a name of your choosing> and the names appear. On the second row the gateway does that for you — it appends each miner's own username to your address, and labels anything nameless by its LAN IP, so you see 192x168x1x50 with the dots turned into x, the dot being the separator.

06Check that it actually works

Four things, in this order. Each one rules out a different failure.

01
The gateway has a session
Its log says hello ok shortly after start. No line means the host, the port or the public key is wrong.
02
Work is being served
A line per new tip: Updating standard stratum job for block …. Silence here means the node has not finished syncing.
03
Shares are accepted
Your miner's own page shows accepted shares climbing and no rejects.
04
You appear in the pool
Within a few minutes your address shows up on the miners page and your own /miner/<address> page starts filling.

When it does not work.

The five things that actually go wrong, and what each one means.

What you see	What it means
no work served at all	The node has not reached the BLAKE2b rule yet, or it is still syncing. Until the template lists !blake2b the gateway deliberately serves nothing rather than hand out work for the wrong chain.
BadUsername	The username before the first dot is not an address this chain accepts. Check it with bitcoin-cli validateaddress <address> on your own node. Mind which username: with pool_pass_full_users: true the gateway forwards each miner's own, so the fix is in the miner and not in datum.pool_username — a gateway whose own address is perfect still has every share refused if one machine authenticates as rig-3. Nothing is credited while that lasts, so such a miner runs for nothing. Our side of the log names it the other way round: payout address "rig-3" cannot be paid: not a valid address.
NoSplit	Your gateway mined a coinbase that paid none of the split the pool had sent it. This is a sign of an outdated or mis-built gateway, not of anything you did — update it.
StaleBlock	A share arrived for a tip that had already moved on. A handful a day is normal. A constant stream means blocknotify is not reaching the gateway.
outputs left out of a block	blockreservedweight is too low, so the coinbase had no room for the whole split. Raise it to 32,000 and restart the node.

Anything else, bring it to the Discord with the gateway's log line. It is usually one setting.

Questions worth asking first.

Do I earn less than miners on the ordinary ports?

No — the same, for the same work. Both paths are split from the same rolling window of the pool's recent work — eight times the network difficulty — and both are paid straight out of the block's coinbase. The fee is 1 % on either. What you gain here is the template: you pick the transactions.

Can I run this on the machine my miner already sits next to?

Yes, and that is the normal arrangement. The gateway is tiny; the node is what needs the disk. Any always-on machine on the same network will do, including a Raspberry Pi 5 with a real SSD. Avoid an SD card — the chainstate will wear it out.

Do I have to open a port to the internet?

No. Your gateway makes an outbound connection to the pool, and your miners reach it over your own network. Nothing needs to be reachable from outside, and the node does not need inbound connections either.

Can my node be pruned?

Yes. Building templates needs the UTXO set and the mempool, not old blocks. Pruning is the recommended setup here and it is what we run ourselves. You do not want txindex either; it costs disk and buys nothing on this path.

What happens if my node or my gateway goes down?

Your miners stop earning while it is down, exactly as they would on any pool, and your work already inside the payout window keeps paying you as it ages out. Nothing is lost and there is nothing to reclaim. Give your miner a second pool slot pointing at our ordinary stratum port and it will fall back on its own.

Does the pool see which transactions I include?

Only afterwards, like everyone else, when the block is published. The pool is handed the block to relay; it never gets the choice of what goes in. That is the whole point of the arrangement.

Why does the pool set the primary coinbase tag and not me?

Because that is the field explorers read to attribute a block, and if every gateway wrote its own, the pool's blocks could not be counted as the pool's. The second tag is yours, we never touch it, and it is the one that identifies you in the block.

Is there a minimum payout?

10,000 satoshi. An output smaller than that costs more to spend than it carries, so it is not written into the block — it is carried forward and paid with your next slice instead. Your miner page shows both figures.