qt: persist Mining tab pool settings across restarts (QSettings) #66

New issue

Closed

opened 2026-08-11 01:23:22 +00:00 by dobbscoin · 1 comment

dobbscoin commented

2026-08-11 01:23:22 +00:00

Split out of #8, which closes with the Stratum client complete.

The Mining tab's pool section reads its fields fresh on every launch: the endpoint arrives prefilled with pool.23skidoo.info:3040, the pay-to address and thread count start empty. Nothing is written back. A worshipper who points the client at a different pool, or who mines to an address other than the wallet default, retypes both every time the client starts.

That lands on exactly the audience pool mode was built for. Solo mining's Poisson variance was the reason for the whole feature — the casual who gives up after four hours of no blocks is the same casual who gives up after typing a Q-address for the third night running.

Scope

Persist and restore the three pool-mode fields through QSettings, alongside how the rest of the client stores its options:

endpoint (host:port)
pay-to / worker address
thread count

Notes

Tab lives in src/qt/forms/rpcconsole.ui; handlers in src/qt/rpcconsole.cpp (0a0f3ccb).
Keep pool.23skidoo.info:3040 as the fallback when no value has been stored — a fresh wallet should still have a working endpoint in the box.
Don't persist a running/stopped state. Mining should never auto-start on launch; the rite is entered deliberately.
Validate on restore the same way the fields validate on entry, so a hand-edited config can't feed a malformed address straight into mining.authorize.

Where this lives

feat/issue-8-mining-tab-solo only. Per maintainer decision the mining lineage never merges to main — stock releases stay lean. CI force-pushes this branch on every push to main, so pull before committing.

Done when

Set endpoint, address, and threads; restart the client; all three come back as entered, and mining does not start on its own.

Split out of #8, which closes with the Stratum client complete. The Mining tab's pool section reads its fields fresh on every launch: the endpoint arrives prefilled with `pool.23skidoo.info:3040`, the pay-to address and thread count start empty. Nothing is written back. A worshipper who points the client at a different pool, or who mines to an address other than the wallet default, retypes both every time the client starts. That lands on exactly the audience pool mode was built for. Solo mining's Poisson variance was the reason for the whole feature — the casual who gives up after four hours of no blocks is the same casual who gives up after typing a Q-address for the third night running. ## Scope Persist and restore the three pool-mode fields through `QSettings`, alongside how the rest of the client stores its options: - endpoint (`host:port`) - pay-to / worker address - thread count ## Notes - Tab lives in `src/qt/forms/rpcconsole.ui`; handlers in `src/qt/rpcconsole.cpp` (`0a0f3ccb`). - Keep `pool.23skidoo.info:3040` as the fallback when no value has been stored — a fresh wallet should still have a working endpoint in the box. - Don't persist a running/stopped state. Mining should never auto-start on launch; the rite is entered deliberately. - Validate on restore the same way the fields validate on entry, so a hand-edited config can't feed a malformed address straight into `mining.authorize`. ## Where this lives `feat/issue-8-mining-tab-solo` only. Per maintainer decision the mining lineage never merges to `main` — stock releases stay lean. CI force-pushes this branch on every push to `main`, so pull before committing. ## Done when Set endpoint, address, and threads; restart the client; all three come back as entered, and mining does not start on its own.

dobbscoin commented

2026-08-11 01:53:41 +00:00

Invalid — this was already implemented in 0a0f3ccb ("qt: Mining tab pool mode — The Communal Rite"), which is the same commit that added the pool section. Closing.

Restore runs in the RPCConsole constructor (src/qt/rpcconsole.cpp:255-269), under the comment "restore last-used settings; reflect a client already started via -stratum/-stratumuser command-line args":

poolMiningEndpoint — defaults to pool.23skidoo.info:3040 when unset, exactly the fallback this issue asked for
poolMiningAddress — defaults empty
poolMiningThreads — qBound(1, saved, idealThreadCount()), so a hand-edited config can't exceed the machine

Write-back is at rpcconsole.cpp:681-683, placed deliberately after StartStratum() returns success — only settings that actually brought up a client get persisted, so a failed endpoint never becomes the saved default.

The other two acceptance criteria hold as well. Values restore through the same widgets that feed the host:port and Q-address validation in on_poolMiningToggle_clicked(), so a hand-edited config still can't reach mining.authorize malformed. And nothing auto-starts: the constructor only checks the toggle when g_pStratumClient is already running from -stratum args or setstratum — a stored endpoint alone does not begin the rite.

Verified in the shipped artifact too. strings on Offerings-qt.exe from Offerings-miningtab-private-20260807-151900-win64.zip (built at wallet-mining-ef3672f) contains poolMiningEndpoint, poolMiningAddress, and poolMiningThreads — the public Windows build persists pool settings today.

My error when filing: I grepped for QSettings on the same line as pool/stratum/mining, and the declaration QSettings settings; sits on a line of its own. Nothing was missing from #8.

Invalid — this was already implemented in `0a0f3ccb` ("qt: Mining tab pool mode — The Communal Rite"), which is the same commit that added the pool section. Closing. Restore runs in the `RPCConsole` constructor (`src/qt/rpcconsole.cpp:255-269`), under the comment *"restore last-used settings; reflect a client already started via -stratum/-stratumuser command-line args"*: - `poolMiningEndpoint` — defaults to `pool.23skidoo.info:3040` when unset, exactly the fallback this issue asked for - `poolMiningAddress` — defaults empty - `poolMiningThreads` — `qBound(1, saved, idealThreadCount())`, so a hand-edited config can't exceed the machine Write-back is at `rpcconsole.cpp:681-683`, placed deliberately **after** `StartStratum()` returns success — only settings that actually brought up a client get persisted, so a failed endpoint never becomes the saved default. The other two acceptance criteria hold as well. Values restore through the same widgets that feed the `host:port` and `Q`-address validation in `on_poolMiningToggle_clicked()`, so a hand-edited config still can't reach `mining.authorize` malformed. And nothing auto-starts: the constructor only checks the toggle when `g_pStratumClient` is *already* running from `-stratum` args or `setstratum` — a stored endpoint alone does not begin the rite. Verified in the shipped artifact too. `strings` on `Offerings-qt.exe` from `Offerings-miningtab-private-20260807-151900-win64.zip` (built at `wallet-mining-ef3672f`) contains `poolMiningEndpoint`, `poolMiningAddress`, and `poolMiningThreads` — the public Windows build persists pool settings today. My error when filing: I grepped for `QSettings` on the same line as pool/stratum/mining, and the declaration `QSettings settings;` sits on a line of its own. Nothing was missing from #8.

dobbscoin closed this issue

2026-08-11 01:53:42 +00:00

No labels

enhancement

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

SubGeniusFinance/Offerings-to-Cthulhu#66

No description provided.

Rows
Columns