EXTENSION · RC Lock extended to 1 Sep 2027 — takes effect at block 979,920 (Knots 29.4.3, release candidate) details

Coinbase maturity · whole chain

Coming at block 979,920: the lock extends to 1 Sep 2027.

Knots 29.4.3 — still a release candidate (v29.4.3.knots20260508rc1) — extends this rule. Every coinbase mined from block 973,440 onward will stay locked until the chain's median time reaches 1 Sep 2027, 00:00 UTC, instead of unlocking at block 979,920. Nodes and miners must upgrade before block 979,920: 2,725 blocks to go (about 2 Nov 2026). Because it is a release candidate, details can still change before the final release; if they do, this notice changes with them. We will run the final release on our node before block 979,920.

Newly mined coins are locked for 6,480 blocks — until block 979,920.

In force since block 973,440. Every coinbase mined from block 973,440 onward cannot move until block 979,920 — 2,725 blocks to go (about 2 Nov 2026).

What PyBLØCK has done. Our node is already running v29.4.2.knots20260508, since 2026-09-21. We said we would upgrade at RC2, and we have.

What that changes for you, plainly. This already applies, and it did not wait for block 973,440: our node no longer passes on a spend of any reward younger than 6,480 confirmations. That is about our node relaying, not about whether the coin is yours: a reward mined before block 973,440 matures at the usual 100 confirmations and your balance shows it as spendable, because it is. Your coins are not frozen and we are not holding them. They are valid, they are already yours on-chain, and any other wallet or node still broadcasts them — most of the network has not upgraded. What changes is our node, not your ownership.

Why this is easier here than elsewhere. Your reward is written straight into the block's coinbase, to your address: it is already yours on-chain, and nothing here is held by us: we cannot spend it, and we are not paid first. A custodial pool instead collects the whole coinbase and pays you later out of its own balance; while that coinbase is locked, it has to fund every payout from reserves. We front nothing, so there is nothing here that can run out.

Why the date is sooner than 45 days: the rule counts blocks, not time. 6,480 blocks is about 45 days at the usual 10-minute spacing, but this chain is currently running faster (~45 days at the recent pace), so the unlock lands earlier. The block height is the part that is fixed; every date here is an estimate that moves with the chain.

Until now a block reward could be moved after 100 blocks, about 16 hours. This is a rule of the Bitcoin BLAKE2b client, not of this pool: it applies to every coinbase on the chain, whoever mined it, and there is nothing we can change from our side. What you are owed does not change — only how long it sits before it moves. Payouts keep being written straight into the block's own coinbase, to your address, with nothing held by us. That also means your share is locked the same way ours is: we are not paid first.

Why this starts before block 973,440. The wallet and relay side of this release applies the long wait to every reward, on purpose and independently of the chain rule — the proposal says so in as many words. We ran the release on an isolated node of our own to be sure: the cut-off sits exactly at 6,480 confirmations whenever the reward was mined, and it already applies with the activation still in the future. So it is not something that gets fixed before the flag day: it is what the client does, and it is a client behaviour rather than a rule of this pool.

The same announcement says that whoever mines without running their own node and gateway is not really mining and might not be paid at all in the future. That is a stated intention in the change itself — not code, and no mechanism for it exists today. We are not going to pretend we know how it would be administered. We tell you because you should have the whole picture. If it ever becomes a real rule, you will read it here first.

What we recommend, for what it is worth. If you are going to be waiting on a longer maturity anyway, this is a good moment to run your own node and DATUM gateway. Not because it exempts you from the wait — it does not, and anyone telling you otherwise is wrong: the rule applies to every coinbase on the chain, whoever built the block. Run it because it is simply better for you. Your node picks the transactions, so we never see your selection and could not censor one if we wanted to. And you keep more, because there is no node-runner cut when you are the node runner: 99% on CAROUSEL, against 98% over our stratum (CHIRP already pays 100% either way: it runs 100% on DATUM). The waiting is the same either way — what changes is how much of the block is yours when it unlocks, and who decided what went into it. How to run it →

Running your own node and gateway is what WAVICLES already does, and it is now available for CAROUSEL and CHIRP too — see PATUM for the one-click installer.

SV1 penalty · from block 977,350

Block 977,350 · about 15 Oct 2026 (155 blocks to go at the current pace)

The penalty we are going to roll out for SV1 endpoints will be so resounding that it will echo across the universe.

Want to mine on a WAVICLES endpoint? Fine — you’ll lose 77% of the block.
Want to mine on a CHIRP endpoint? Fine — you’ll lose 77% of the block.
Want to mine on a CAROUSEL endpoint? Fine — you’ll lose 78% of the block.
Want to mine on a SUPPLIER endpoint? Fine — you’ll lose 78% of the block.

	Your own node	Public stratum	Supplier endpoint
CHIRP	0% pool	77% pool	—
WAVICLES	0% pool	77% pool	—
CAROUSEL	1% pool	77% pool + 1% supplier	1% pool + 77% supplier

Rentals: from that block, rented hashrate goes only to your own DATUM gateway. Orders already running finish where they are.Run PATUM →

WAVICLES

bring your own node · DATUM · BLAKE2b

LIVE

Your node builds the block. The pool only sets the split: everyone with work in the window, by work · fee 0% with your own node, 0% through PyBLØCK’s stratum · paid in the coinbase. The pool never holds a sat.

Connect your node →

—

Pool hashrate

—

Node runners

—

Miners in window

—

Blocks found

—

Miners via PyBLØCK’s node

—

Miners on their own node

Hashrate · 24h block mined—

Next block · who gets paid

—

to miners · block value − fee (0% node · 0% house)

— of the window credited—

Miner	Hashrate · 10 min	Share of window	Would receive	Last share
No work in the window yet — connect a node and the split appears here.

Would receive = the split the pool dictates right now: everyone with work in the window, by work, minimum 1,000 sats. If a block is found by a miner whose firmware can only carry a small coinbase, the split is pro-rated among those who fit — never kept by the pool.

Under ~100 MH/s? Your share of a block may stay below the 1,000-sat minimum (the threshold grows with the pool). CHIRP suits you better: it weights tenure and has no per-block minimum → CHIRP.

Blocks found

Block	When	Built by	Paid to miners	Pool output	Miners paid
No WAVICLES blocks yet — the first one shows up here and on BLOCKS.

Pool output = exactly the fee: 0% since 2 October 2026 (before: 0.4% on work from your own node, 2.9% through PyBLØCK’s stratum), so blocks from then on carry no pool output. Everything else is paid to the window in that same coinbase, by share of work (minimum 1,000 sats per identity; below that your share goes to the other miners, never to the pool). Blocks #970075 and #970309 were paid under the earlier carry rule; that legacy carry is being paid out manually.

Node runners connected

Gateway	Software	Shares	Work	Connected	Last share
No gateways connected right now.

—

Charts

Pool hashrate

Window credited · % and miners

Blocks per day · found vs expected

More charts · node runners, shares

Node runners connected

Shares per hour · accepted / rejected

collecting live data…

Connect · your DATUM gateway

New here? Get started in four steps →

"mining": {
  "pool_address": "YOUR_BLAKE2B_ADDRESS",
  "coinbase_tag_secondary": "your-name"
},
"datum": {
  "pool_host": "b.pyblock.xyz",
  "pool_port": 28915,
  "pool_pubkey": "b5e0b0326b964a92f3046c73a76b9e98173e0c3ea0e0ca771f4e6a3dd92e2935b2caad2a088fdd7bf0a48fc0c41776a9abb13c7d4c6964b53a9ceee4c775e036",
  "pool_pass_workers": true,
  "pool_pass_full_users": true,
  "pooled_mining_only": true
},
"stratum": {
  "vardiff_min": 1,
  "vardiff_target_shares_min": 8
}

mining.pool_address = your address. Your share of every block is paid there, in the coinbase.
mining.coinbase_tag_secondary = your name. It goes on-chain in the scriptsig: PyBLOCK-WAVICLES-BLAKE2b/your name.
Point your miners at your own gateway, never at the pool. Any BLAKE2b miner works (GPU, CPU, Sia ASICs).

Needs a Bitcoin Knots BLAKE2b node and a DATUM gateway: CONVOY (master ≥ 2026-09-02), OCEAN-lineage forks, StartOS packages.

Troubleshooting & node settings

CONVOY users: build from CONVOYMining/datum_gateway master on or after 2026-09-02 (commit b9ea7dc+). Older builds fail after the handshake with "Invalid data structure in configuration" — pull, rebuild, reconnect; your config does not change.

Symptom in the gateway log	Cause	Fix
`Invalid data structure in configuration` → `Waiting on DATUM server… 0`	CONVOY build older than 2026-09-02	update to master (≥ `b9ea7dc`), rebuild, reconnect
`decryption failed`	`pool_pubkey` wrong or truncated	copy the full 128-hex key (click the config block), restart the gateway
Handshake OK but 0 shares on the pool	miners point at the pool instead of your gateway	miners go to `gateway-IP:stratum-port`, never to `:28915`
miners hash on your gateway, still 0 shares after 30+ min	DATUM’s default share floor `vardiff_min = 16384` is SHA-256 ASIC scale; a BLAKE2b GPU or CPU never reaches it	`"stratum": {"vardiff_min": 1}` (a power of two; 1 is what PyBLØCK’s own GPU gateway runs), restart the gateway
"pool-only" coinbase in a block	template left no room for the payout outputs	`blockreservedweight=100000` in your node’s bitcoin.conf
connects, then drops every few minutes with a new gateway key each time	the gateway restarts right after the handshake: its node returns no BLAKE2b work (RPC misconfigured, not synced, or missing the `blake2b` rule)	read the gateway log after "DATUM Pool MOTD"; on your node run `bitcoin-cli getblocktemplate '{"rules":["segwit","blake2b"]}'`
your identity shows work but payout 0 / "not payable"	the miner username on your gateway is a worker name, not an address	miners log in with a Bitcoin-BLAKE2b address (`bc1q…` / `1…`); a worker after a dot is fine: `bc1q….rig1`
few identities paid in a block	a coinbase budget too small for the payout list	fixed pool-side on 2026-09-14: every gateway now gets the 16 KB class (~400 payouts), stock CONVOY included. Nothing to change on your side.

Node tip: blockreservedweight=100000 in bitcoin.conf. The Knots default leaves room for ~55 coinbase outputs. Your miners’ firmware sets how many payouts a coinbase can carry: modern firmware (Whatsminer, S21, ePIC) takes big coinbases and pays the whole window; a stock ~730-byte coinbase fits ~15, and then the split is pro-rated among those who fit — never kept by the pool. With a big window your coinbase can carry hundreds of outputs (each bech32 payout = 124 WU); reserve weight for it so it never displaces transactions. Bitcoin-BLAKE2b templates are ~110 kWU today, so there is room to spare.

DATUM endpoint b.pyblock.xyz:28915 · pool pubkey b5e0b0326b964a92f3046c73a76b9e98173e0c3ea0e0ca771f4e6a3dd92e2935b2caad2a088fdd7bf0a48fc0c41776a9abb13c7d4c6964b53a9ceee4c775e036

Running your own node · FAQ

The one thing people get wrong: your address goes in two places, and they do different jobs. In mining.pool_address it decides who gets paid if you ever mine without the pool, and the gateway will not even start without a valid one. On each miner, as the Stratum username, it decides who gets credited in the window. Set both. Then check the Node runners table above: shares climbing means it worked.

What do I need, and in what order?

Three pieces, set up in this order. 1. A Bitcoin Knots node with BLAKE2b, fully synced. 2. A DATUM gateway on the same machine or LAN, pointed at your node over RPC and at WAVICLES over the internet. 3. Your miners, pointed at your gateway. Any BLAKE2b miner works: GPU, CPU, or a Sia-class ASIC. Do not skip ahead. A gateway whose node is not ready will connect to us, sit at zero and look healthy from the outside.

Where exactly does my payout address go?

1. In the gateway config, as mining.pool_address. It is required. With an invalid one the gateway prints Could not generate output script for pool addr and exits in under a second, so if your gateway is running at all, this field is already fine. It is also the address that collects 100% of any block you find while the pool is unreachable, which is the case below.

2. On every miner, as the Stratum username. Password is ignored, use x. A worker name after a dot is fine: bc1q….rig1. With the config we publish above (pool_pass_full_users: true) this username is what we credit, so each miner on your gateway is paid to whatever address it logs in with.

Careful with that flag. Set pool_pass_full_users to false and every miner on your gateway is credited to mining.pool_address instead, whatever your miners type. That is the right setting if the rigs are all yours, and the wrong one if you are hosting somebody else.

Does the gateway check that my miner’s username is a real address?

No. It forwards the username as it was typed. The check happens here: a username that is not a payable BLAKE2b address is rejected as bad-username, and those shares earn nothing. So a typo costs you real work, silently, until you look. Always re-check after changing a username: your row in the Node runners table should show shares going up and rejects staying flat.

My gateway shows up connected, but 0 shares. What now?

Connected with zero shares means we are talking to your gateway and nothing is hashing into it. In order of how often it happens: no miner is pointed at the gateway yet; the miners are pointed at :28915, which is where your gateway talks to us and never where miners go; or they are on a GPU or CPU and never reach the default share floor, which is sized for SHA-256 ASICs. For that last one set "stratum": {"vardiff_min": 1} and restart. Your gateway’s own Clients tab is the fastest way to tell the first case from the rest: if it is empty, the problem is on your side of the gateway, not between us.

What happens if WAVICLES goes offline?

That is what pooled_mining_only decides. Left at true, as we publish it, your gateway drops your miners rather than mine without a pool. Set to false, your node keeps building blocks on its own and any block it finds pays 100% to mining.pool_address. Neither is wrong. The first keeps your hashrate from going somewhere you did not choose; the second keeps it earning. It is also the second reason that field has to be an address you actually control.

Do I only get paid when my own node finds a block?

No, and this is the whole point of the pool. Every block found by anyone on WAVICLES pays everyone with work in the window, by share of work, in that same block’s coinbase. You are paid by the block’s finder directly on-chain. The pool never holds a sat and there is nothing to withdraw.

Is there a minimum, and what does the fee cost me?

Minimum: 1,000 sats accrued in the window. Below that your share is spread across the miners who do clear it. It is never kept by the pool. Fee: 0%, whether your own node builds the block or you mine through PyBLØCK’s Stratum.

Which gateway build should I run?

CONVOY at commit 7491a509 or later. Builds before it miscount the BLAKE2b coinbase bytes and truncate the payout list, so a block found on one would leave most of the window unpaid. We refuse those at the handshake with a message saying so, rather than let you find out on a block. Note that a plain git pull of master is not enough if master still carries the bug. OCEAN-lineage forks and StartOS packages work too.

Still stuck? The Troubleshooting table above maps the exact line in your gateway log to its cause.

How it works

DATUM, not a stratum. Your gateway builds the whole block from your own node and submits it. The pool only answers with the coinbase split.
Work window. Accepted work is credited to your address in a rolling window of 8× the network difficulty. Any block found by anyone in the window pays everyone in it, by share of work.
Paid in the coinbase. Every block pays everyone with work in the window, in the coinbase, by share of work: the full block value (0% fee), minimum 1,000 sats per identity — below that your share goes to the other miners of the window, never to the pool. Nothing is ever owed and nothing is held.

Verify a block yourself

Output 0 of every coinbase is OP_RETURN PYBLOCK-TON618 ‖ BLAKE2b-256(snapshot). The snapshot (window, params, split) is public at wavicles_api.php?mode=snapshot&hash=… and cannot change after the block exists.
Recompute the split from public data: hash(snapshot) == the OP_RETURN, the split recomputed from window + params (max_payees) == the snapshot’s payees, every payee paid on chain.
The scriptsig carries PyBLOCK-WAVICLES-BLAKE2b/<node-runner> — the node that built the block.

python3 tools/verify_wavicles_block.py --height H \
  --conf bitcoin.conf --url https://b.pyblock.xyz/wavicles_api.php

Verifier + pool source: gitlab.com/astrolexis-group1/wavicles-prime (MIT).