Disable job declaration for the MVP: refuse custom jobs, drop the JD server and client #39

New issue

Open

opened 2026-10-09 18:35:11 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-09 18:35:11 +01:00

Collaborator

Primary goals:

The pool refuses custom jobs — SetCustomMiningJob is answered with an error (a new code such as custom-jobs-disabled) regardless of its contents, behind a pool config flag that defaults to off, so a job-declarator client cannot mine on its own template through this pool.
JD leaves the stack — jd-server and jd-client are removed from the dev processes, the systemd units, the control and ship scripts, and the build and coverage scripts; their configs go with them, and the pool's display-only jd_server_address is dropped or left unset.
The decision is written down — the README or docs/EPOCH_DESIGN.md states that the MVP runs without job declaration and why: with the pool building every template, "is this reward block ours" is a lookup against the pool's own template log rather than a tag or signature scheme, and template validation (vnprc/hashpool#20) is not needed for the pool's own miners.
Re-enabling is gated, not forgotten — turning job declaration back on requires vnprc/hashpool#20 (template validation) to land first, because an accepted custom job is exactly the surface that validation exists to check.

Current state and specifics

The dev stack runs both JD roles today: devenv.nix defines the jd-server and jd-client processes, config/jds.config.toml listens on 127.0.0.1:34264, and config/jdc.config.toml listens for miners on 127.0.0.1:34265 and uses the pool at 34254 as its upstream. Nothing mines through that path: the translator's upstream in config/tproxy.config.toml is the pool directly (127.0.0.1:34254), so the JDC sits idle with no downstream. The deployment carries the same pair as scripts/systemd/hashpool-jd-server.service and hashpool-jd-client.service, listed in scripts/hashpool-ctl.sh and started and stopped by scripts/ship.sh. The pool's jd_server_address (roles/pool/src/lib/config.rs:37) is for display only.

Idle is not off. The pool accepts SetCustomMiningJob from any extended channel: roles/pool/src/lib/mining_pool/message_handler.rs:1260 (handle_set_custom_mining_job) checks only that the pool's payout script appears somewhere among the custom coinbase outputs, and its own comment records that the amount of that output is not checked. A miner running a job-declarator client can therefore declare a template whose coinbase pays the pool's script one satoshi and the rest to themselves, mine on it through the pool, earn ehash for every share, and keep the block reward if they find a block. With the automatic reward trigger (vnprc/hashpool#37) that found block is also a reward at the mint's receive script, which is the dust rotation described in vnprc/hashpool#38, performed from inside the pool.

Refusing the message closes this at the pool. The mint-side floor in vnprc/hashpool#38 stays as defence in depth against block builders who are not on this pool at all; the two are complementary, not alternatives.

Scope

In scope: the refusal in the pool with a config flag (default: custom jobs disabled) and a unit test that a SetCustomMiningJob gets the error; removing the two JD processes, their configs, units and script references; the one-paragraph decision in the docs. Validation: the dev stack starts and mines with the two processes gone; a job-declarator client pointed at the pool is refused with the new error code in its log; scripts/ship.sh and hashpool-ctl.sh run without the units. Out of scope: vnprc/hashpool#38 (mint-side reward floor), vnprc/hashpool#20 (template validation, which re-enabling JD depends on), and any change to how the pool obtains templates from sv2-tp, which is unchanged.

Part of vnprc/hashpool#13.

Disable job declaration for the minimum viable pool: the pool refuses custom mining jobs, and the job-declarator server and client leave the dev stack and the deployment, so every block a miner finds is built from a template the pool produced and the pool knows every coinbase it has ever paid itself with. Primary goals: - **The pool refuses custom jobs** — `SetCustomMiningJob` is answered with an error (a new code such as `custom-jobs-disabled`) regardless of its contents, behind a pool config flag that defaults to off, so a job-declarator client cannot mine on its own template through this pool. - **JD leaves the stack** — `jd-server` and `jd-client` are removed from the dev processes, the systemd units, the control and ship scripts, and the build and coverage scripts; their configs go with them, and the pool's display-only `jd_server_address` is dropped or left unset. - **The decision is written down** — the README or `docs/EPOCH_DESIGN.md` states that the MVP runs without job declaration and why: with the pool building every template, "is this reward block ours" is a lookup against the pool's own template log rather than a tag or signature scheme, and template validation (vnprc/hashpool#20) is not needed for the pool's own miners. - **Re-enabling is gated, not forgotten** — turning job declaration back on requires vnprc/hashpool#20 (template validation) to land first, because an accepted custom job is exactly the surface that validation exists to check. ### Current state and specifics The dev stack runs both JD roles today: `devenv.nix` defines the `jd-server` and `jd-client` processes, `config/jds.config.toml` listens on `127.0.0.1:34264`, and `config/jdc.config.toml` listens for miners on `127.0.0.1:34265` and uses the pool at `34254` as its upstream. Nothing mines through that path: the translator's upstream in `config/tproxy.config.toml` is the pool directly (`127.0.0.1:34254`), so the JDC sits idle with no downstream. The deployment carries the same pair as `scripts/systemd/hashpool-jd-server.service` and `hashpool-jd-client.service`, listed in `scripts/hashpool-ctl.sh` and started and stopped by `scripts/ship.sh`. The pool's `jd_server_address` (`roles/pool/src/lib/config.rs:37`) is for display only. Idle is not off. The pool accepts `SetCustomMiningJob` from any extended channel: `roles/pool/src/lib/mining_pool/message_handler.rs:1260` (`handle_set_custom_mining_job`) checks only that the pool's payout script appears somewhere among the custom coinbase outputs, and its own comment records that the amount of that output is not checked. A miner running a job-declarator client can therefore declare a template whose coinbase pays the pool's script one satoshi and the rest to themselves, mine on it through the pool, earn ehash for every share, and keep the block reward if they find a block. With the automatic reward trigger (vnprc/hashpool#37) that found block is also a reward at the mint's receive script, which is the dust rotation described in vnprc/hashpool#38, performed from inside the pool. Refusing the message closes this at the pool. The mint-side floor in vnprc/hashpool#38 stays as defence in depth against block builders who are not on this pool at all; the two are complementary, not alternatives. ### Scope In scope: the refusal in the pool with a config flag (default: custom jobs disabled) and a unit test that a `SetCustomMiningJob` gets the error; removing the two JD processes, their configs, units and script references; the one-paragraph decision in the docs. Validation: the dev stack starts and mines with the two processes gone; a job-declarator client pointed at the pool is refused with the new error code in its log; `scripts/ship.sh` and `hashpool-ctl.sh` run without the units. Out of scope: vnprc/hashpool#38 (mint-side reward floor), vnprc/hashpool#20 (template validation, which re-enabling JD depends on), and any change to how the pool obtains templates from sv2-tp, which is unchanged. Part of vnprc/hashpool#13.

vnprc-agent referenced this issue

2026-10-09 18:35:11 +01:00

Reward detection: refuse dust coinbase outputs so a block builder cannot force an epoch rotation #38

vnprc-agent referenced this issue

2026-10-09 23:06:46 +01:00

mint: automatic reward trigger with reorg-safe epoch boundaries #37