v2.4.0

Running your own pool? Start with DEPLOYMENT.md and the new simple-setup/ directory.

Upgrading an existing pool? This release changes the config layout. Read Upgrade notes at the bottom before you update: an old config no longer loads.

A simple setup for running your own pool

• simple-setup/ runs the pool as two processes (front,api and payout,stats,notify) with Postgres and Valkey from one docker-compose.yml. A Bitcoin Core 31 node is included as an optional profile (mainnet, testnet4 or regtest); your own node works too, through its IPC socket directory. Storage lives in Docker volumes, so there is nothing to prepare, and a .env file is optional.
• DEPLOYMENT.md walks through it end to end, including a regtest run with CPU miners to see the whole path work in a few minutes, switching on PPLNS, Group-Solo and Blockparty, updates and backups.
• blitzpool.example.toml is now a complete, working Solo pool; blitzpool.full.example.toml documents every section and key.
• full-setup/ is unchanged and remains the four-process layout for redeploying the API, payouts and notifications one at a time.

Stratum V2 keys

• blitzpool --sv2-keygen (or docker compose run --rm --no-deps front --sv2-keygen) prints a new [sv2] authority_privkey_hex together with the public key SV2 miners and JD clients pin. It decodes the key the same way the pool does at start.
• The front logs its authority public key on every start (stratum-v2: authority public key). Until now the pool printed it nowhere.

Configuration: each payout mode owns its section

• [solo], [pplns], [group_solo] and [blockparty] each carry their own fee_address, fee_percent, coinbase weight budget and minimum payout. Nothing is inherited from another section any more; on Solo the fee stays optional.
• Group-Solo is switched on by [group_solo], like PPLNS and Blockparty by theirs. Without it the pool runs no Group-Solo engine and template stream, and the API refuses to create a group. A pool that is Solo only no longer needs a fee address.
• With [group_solo] absent the pool refuses to start while active groups exist, so no member is moved to Solo without the operator noticing.
• The block reconcile check recognises every mode's fee address as the pool's, so a Group-Solo or Blockparty block paying its own fee address is checked like any other.

API

• /api/pplns/fees no longer fails without Group-Solo. groupFeePercent is null while Group-Solo is off, and the new blockpartyFeePercent reports the Blockparty fee, which can now differ from the Group-Solo fee.

Fixes

• The startup hint for a Group-Solo config error pointed at the Solo fee keys; it now names the [group_solo] keys.
• The documentation of [sv2] authority_privkey_hex claimed a random key is generated when it is missing. The front requires it; the documentation says so.

Dependencies

• hashbrown 0.17, getrandom 0.4, base64 0.23.
• async-channel stays on 1.x: its channel types cross the boundary to the Bitcoin Core IPC layer from sv2-apps and must match its version. Dependabot no longer proposes its majors.

Upgrade notes

• The config layout changed, and an old config fails to load. The error names one place that no longer fits, not necessarily the first in the file: for example missing field fee_address at [blockparty], or unknown field group_fees. Nothing changes silently. Convert the config before deploying the new version:

  Before	After
  [group_fees] address	[group_solo] fee_address and [blockparty] fee_address
  [group_fees] percent	[group_solo] fee_percent and [blockparty] fee_percent
  [group_fees] coinbase_weight_budget	[group_solo] coinbase_weight_budget
  Group-Solo / Blockparty fee taken from [pplns] when [group_fees] was absent	set fee_address and fee_percent in [group_solo] and [blockparty]
  Group-Solo minimum payout taken from [pplns] min_payout_sats	[group_solo] min_payout_sats (default 5000)
  [solo] dev_fee_address, dev_fee_percent	[solo] fee_address, fee_percent
  Group-Solo always on	add [group_solo] to keep it running

  Example: a config with [group_fees] address = "bc1q…", percent = 1.5, coinbase_weight_budget = 25000 and [pplns] min_payout_sats = 5000 becomes

  [group_solo]
  fee_address = "bc1q…"
  fee_percent = 1.5
  coinbase_weight_budget = 25000
  min_payout_sats = 5000
  
  [blockparty]
  fee_address = "bc1q…"
  fee_percent = 1.5
  # existing min_payout_sats / coinbase_weight_budget stay

• Switch the config and the image together. Every process reads the config only at start: running processes keep working, but a process of the old version that restarts with the new config fails, and the new version does not start with the old one. Convert the config, then recreate all pool processes on the new image.

• Check the converted file before the swap with blitzpool --config <file> --check-config (or docker compose run --rm --no-deps <service> --config /app/blitzpool.toml --check-config).

• No new migrations.

• UI consumers of /api/pplns/fees: show blockpartyFeePercent for Blockparty instead of groupFeePercent, and treat null as "mode off".