[1.0.3] - 2026年06月14日

Hotfix — validate the Monero payout address is a primary address, so nobody silently mines to an
address that can't be paid. The published images are unchanged from 1.0.1; the fix is in the pithead
CLI (re-download the bundle / pithead upgrade to pick it up).

Fixed

• Reject non-primary Monero wallet addresses (#250). p2pool pays out via coinbase, which cannot
  send to a subaddress (8...) or an integrated address — it needs a primary/standard address
  (4..., 95 chars), and XvB credits by the same address. Previously a subaddress passed validation, the
  stack mined, and rewards silently went nowhere. Now setup re-prompts on a bad address, apply
  hard-fails with a message that names the mistake (subaddress vs integrated vs malformed), and doctor
  flags an existing install whose payout address can't be paid.

Already running an earlier version? Run ./pithead doctor — it tells you whether your Monero payout
address is a subaddress (i.e. you've been mining unpaid). Install/upgrade: see
Getting Started and Updating the stack.

Ingredients — Pithead v1.0.3

• Version: 1.0.3
• Commit: 3f9f8e94de121e330f7a466f7a3ec65f3bc9fa6f
• Built: 2026年06月15日T02:47:11Z

Published images (ghcr.io/p2pool-starter-stack, tags v1.0.3 + latest)

• ghcr.io/p2pool-starter-stack/pithead-tor:v1.0.3
  • digest: ghcr.io/p2pool-starter-stack/pithead-tor@sha256:320a4cfa741d6fff64129546e6e990e10f22e64b66a387703689b8b57a770118
• ghcr.io/p2pool-starter-stack/pithead-monero:v1.0.3
  • digest: ghcr.io/p2pool-starter-stack/pithead-monero@sha256:f2b3b1ec72eeff0d1e9c5fa0e9b0b61dc9e88fed1bedb534cc135c001cf09f6a
• ghcr.io/p2pool-starter-stack/pithead-p2pool:v1.0.3
  • digest: ghcr.io/p2pool-starter-stack/pithead-p2pool@sha256:6aca87b0d5d96e63ce3aeda7e0caf1e105b9d5f8d73829055eb5970f49c6d6eb
• ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy:v1.0.3
  • digest: ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy@sha256:ae62a96a04e5cd086b6556047895020f12a9b194c3aa02131bcfda45e9544396
• ghcr.io/p2pool-starter-stack/pithead-dashboard:v1.0.3
  • digest: ghcr.io/p2pool-starter-stack/pithead-dashboard@sha256:432ebb0a61f4e9975200a30ac1855a3d17a2d61e5f605f23ff5996574061da0e

Upstream component pins

• p2pool: v4.16
• monerod: v0.18.5.0
• xmrig-proxy: 6.26.0
• tor base: alpine:latest@sha256:5b10f432ef3da1b8d4c7eb6c487f2f5a8f096bc91145e68878dd4a5019afde11
• tari: quay.io/tarilabs/minotari_node:v5.3.1-mainnet@sha256:824fd6ec21d618805317d7eede374d6782906eeae17d2fc8aaad4df6205f94e0
• caddy: caddy:2.11.4@sha256:cfeb0b281bc44a5a51fecde39e9e577c60d863c0b6196e6bbdf58fd00960887f
• docker-socket-proxy: tecnativa/docker-socket-proxy:v0.4.2@sha256:1f3a6f303320723d199d2316a3e82b2e2685d86c275d5e3deeaf182573b47476

[1.0.2] - 2026年06月14日

Packaging-only patch — the published images are byte-identical to 1.0.1; nothing in the running
stack changed. It exists because releases are immutable, so 1.0.1's install bundle couldn't be corrected
in place. See v1.0.1 for the
full feature set (P2Pool v4.16, optional clearnet initial sync, dashboard, ...).

Fixed

• The install bundle is now complete and has a stable download URL. It ships config.json.template
  (the basic quick-start config — just the two payout addresses) alongside the advanced example, and is
  attached as a versionless pithead.tar.gz so
  https://github.com/p2pool-starter-stack/pithead/releases/latest/download/pithead.tar.gz always
  fetches the latest release. 1.0.1's bundle shipped only the advanced example under a versioned name,
  and — because releases are immutable — could not be fixed in place (#247).

Install

curl -fsSL https://github.com/p2pool-starter-stack/pithead/releases/latest/download/pithead.tar.gz | tar xz
cd pithead && cp config.json.template config.json # set your Monero + Tari payout addresses
./pithead setup

See Getting Started and Updating the stack.

Ingredients — Pithead v1.0.2

• Version: 1.0.2
• Commit: d4a7121cf269ef31b54c970e2690284926a6ac70
• Built: 2026年06月14日T06:19:41Z

Published images (ghcr.io/p2pool-starter-stack, tags v1.0.2 + latest)

• ghcr.io/p2pool-starter-stack/pithead-tor:v1.0.2
  • digest: ghcr.io/p2pool-starter-stack/pithead-tor@sha256:ce1dc3318ab1c360695938d546bf9a6bc1c91e8cf6ae5d92c145f72666fabcf4
• ghcr.io/p2pool-starter-stack/pithead-monero:v1.0.2
  • digest: ghcr.io/p2pool-starter-stack/pithead-monero@sha256:5c6af7301e246c0861dc109a84a250c8a897ec315ea9da7e5a647aad36d8391e
• ghcr.io/p2pool-starter-stack/pithead-p2pool:v1.0.2
  • digest: ghcr.io/p2pool-starter-stack/pithead-p2pool@sha256:b407e078712cfcdcccf483aa5ddc3c636abdcb948cf0bcdeda37fddcd1757940
• ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy:v1.0.2
  • digest: ghcr.io/p2pool-starter-stack/pithead-xmrig-proxy@sha256:6dc2f6242a4967614ba55da6f8f4023d44b21d5ca9c1ca45a1e5b17f4a2049f7
• ghcr.io/p2pool-starter-stack/pithead-dashboard:v1.0.2
  • digest: ghcr.io/p2pool-starter-stack/pithead-dashboard@sha256:f1def12bbeaa6a1ec25b9ec05fd8dc721d600815af5ece1050813f504ca3e011

Upstream component pins

• p2pool: v4.16
• monerod: v0.18.5.0
• xmrig-proxy: 6.26.0
• tor base: alpine:latest@sha256:5b10f432ef3da1b8d4c7eb6c487f2f5a8f096bc91145e68878dd4a5019afde11
• tari: quay.io/tarilabs/minotari_node:v5.3.1-mainnet@sha256:824fd6ec21d618805317d7eede374d6782906eeae17d2fc8aaad4df6205f94e0
• caddy: caddy:2.11.4@sha256:cfeb0b281bc44a5a51fecde39e9e577c60d863c0b6196e6bbdf58fd00960887f
• docker-socket-proxy: tecnativa/docker-socket-proxy:v0.4.2@sha256:1f3a6f303320723d199d2316a3e82b2e2685d86c275d5e3deeaf182573b47476

⬆️ A newer release is available — install v1.0.2

v1.0.2 is a packaging-only patch (identical images) with the complete install bundle + the stable pithead.tar.gz download. Use it instead of the instructions below.

[1.0.1] - 2026年06月13日

First installable stable release. Supersedes 1.0.0, whose published images were arm64-only
(built on an Apple-Silicon host) and whose install bundle was incomplete — it could not run on
x86_64. No feature changes from 1.0.0; the fixes are entirely in the release pipeline (correct
linux/amd64 image builds + a complete install bundle). 1.0.0 is kept as a superseded tombstone at
the bottom.

Bundled, SHA-pinned upstream components: P2Pool v4.16, Monero v0.18.5.0, XMRig-proxy
6.26.0, Tari/minotari_node v5.3.1-mainnet, Caddy 2.11.4, docker-socket-proxy v0.4.2.
The exact image digests for each release ship in the GitHub Release's ingredients manifest.

monerod follows P2Pool v4.16's recommendations where they're compatible with the Tor-first model:
in-peers=64 (the inbound/open-files cap) is honored exactly, and the optional clearnet initial sync
(#183) runs monerod as a clearnet node should — out-peers=32 + P2Pool's recommended priority nodes
(p2pmd.xmrvsbeast.com, nodes.hashvault.pro) for that window. The DNS-based recommendations
(priority hostnames, DNS blocklist/checkpointing) stay off in Tor mode — they leak clearnet DNS
(#161) — with monerod's compiled-in checkpoints as the substitute. ./pithead doctor now also checks
that the system clock is NTP-synchronized (clock skew gets shares/blocks rejected), per P2Pool's
"synchronize your clock before mining" guidance.

Install / Upgrade

New install — clone the repo (or download the pithead-v1.0.1.tar.gz install bundle from the GitHub Release's assets) and follow the quickstart (./pithead setup).

Upgrade an existing (source) checkout:

git pull
./pithead upgrade

./pithead upgrade re-renders the generated config itself — the P2Pool v4.16 monerod settings (out-peers, the clearnet-window priority nodes) and the new doctor clock check are picked up automatically — then rebuilds and recreates only the containers that changed. No separate ./pithead apply is needed for this release, and your config.json plus preserved secrets (Tor onions, RPC credentials, proxy token) are kept untouched. Run ./pithead apply only when you edit config.json — e.g. to opt into the new, default-off clearnet initial sync. Verify afterwards with ./pithead status and ./pithead doctor.

See docs/operations.md for the full lifecycle reference.

Added

• Optional clearnet initial sync (#183). A default-off, per-component opt-in
  (monero.clearnet_initial_sync / tari.clearnet_initial_sync) that lets a node do its one-time
  initial block download over clearnet — much faster than over bandwidth-capped Tor circuits, which
  can crawl at near-zero blocks/sec — then return to Tor for all ongoing operation. When on, Monero
  drops its Tor P2P proxy= (lowering out-peers 48 → 16) but keeps tx-proxy=tor, so
  transaction-origin privacy is preserved and wallets are never exposed; Tari switches its transport
  to TCP and re-enables the seeds.tari.com DNS seed (its onion peer_seeds are unreachable without
  Tor). The only exposure is node-existence — your host IP is visible to that chain's P2P network
  for the sync window. Privacy-first by construction: off by default, a ⚠ disruptive-change
  confirmation on apply, a persistent "CLEARNET INITIAL SYNC ACTIVE — node IP exposed" banner in
  status/up, a doctor warning (and a green "Tor-only" check when off), and a matching warning in
  the monerod container logs — so a node is never silently left on clearnet. Exposed in
  config.advanced.example.json; documented with a full threat model in docs/privacy.md, plus
  docs/configuration.md, docs/getting-started.md, and docs/hardware.md.

• Automatic clearnet → Tor switch-back once synced (#234). The clearnet initial sync (above) no
  longer needs a manual flip back. The dashboard watches each chain's sync state and, the first time
  a clearnet node reports fully synced, writes a persistent marker and restarts the daemon — which
  comes back up Tor-only and stays there across restarts, apply, and reboots (the marker, not
  the flag, is the source of truth, so a synced node can never be silently re-exposed). Monero and
  Tari transition independently. Fail-safe: the marker is persisted before the restart and a failed
  switch is retried, never leaving a node stranded on clearnet; the status/up banner and doctor
  warning clear themselves once a node is genuinely back on Tor. Re-arm a fresh clearnet sync by
  toggling the flag off and on. Mechanism: a shared clearnet-state dir (dashboard rw, monerod/tari
  ro) drives the daemon entrypoints' Tor-vs-clearnet decision; pithead always renders the canonical
  Tor config. Closes #234.

• Dashboard "new release available" badge (#224). The dashboard periodically checks GitHub for
  the latest Pithead release and, if it's newer than the running version, shows a header badge next to
  the version badge — "New release vX.Y.Z available ↗" — linking straight to the release page.
  Notify-only: it never updates anything; you upgrade with ./pithead upgrade on your own terms
  (the one-click upgrade is the separate #59). On by default because the check is routed over
  Tor (the same bridge SOCKS as the XvB fetch, socks5h so the DNS lookup goes through Tor too) —
  GitHub sees a Tor exit, not your IP, so it leaks nothing about you; it's cached hourly and fails
  silently offline. Set dashboard.check_for_updates: false to opt out. Documented in
  docs/configuration.md + docs/privacy.md.

• Release pipeline — scripts/release.sh (make release) (#44). A single entry point, run from
  the private build/test server, that cuts a versioned release end to end: preflight (clean tree,
  SemVer from VERSION, tag-not-already-released, resolve the component pins) → blocking test gate
  (make test + the #54 live integration matrix) → build the 5 first-party images with OCI labels +
  PITHEAD_RELEASE=1 → push to a staging :vX.Y.Z-rc.N tag and capture digests → smoke-verify the
  pushed images from the registry → promote by digest to :vX.Y.Z + :latest (no rebuild, so
  the release is bit-for-bit what was tested) → publish the GitHub Release with an ingredients
  manifest (promoted digests + upstream pins) and a pinned install bundle. Safe by construction:
  --dry-run previews the whole plan, it never starts the live stack on the build host, and it never
  prints the registry token. Images publish to ghcr.io/p2pool-starter-stack/pithead-*
  (override via PITHEAD_REGISTRY / PITHEAD_IMAGE_PREFIX). Release installs pull the published
  images — no local build: each compose service carries an image: .../pithead-<svc>:${STACK_VERSION}
  ref alongside build:, and pithead auto-selects the mode — a source checkout (Dockerfiles present)
  builds locally and tags :dev (--pull never); a release bundle (no Dockerfiles, just
  pithead+VERSION+compose+build/tari/) resolves STACK_VERSION from VERSION and pulls
  :vX.Y.Z (--pull missing). So a release is ./pithead setup with no compile wait.

• Chart hashrate-averaging-window toggle (#168). A new Avg control on the dashboard chart
  plots any of xmrig-proxy's five native averaging windows — 1m / 10m / 1h / 12h / 24h. It's
  separate from the existing time-Range buttons: Range sets how much time the x-axis spans, Avg
  sets how smooth each point is (short windows react to a rig dropping/joining within a poll or two;
  long windows show the underlying trend). 10m is the default, so the chart is unchanged unless
  you switch — and the choice persists across reloads. Every option plots a true average for its
  window (the old headline "15m" was really the proxy's 10m relabeled; that's gone). All five windows
  are now captured per poll and persisted in their own history columns (additive migration, so
  existing databases upgrade in place); per-window history is forward-only, and the 12h/24h
  averages need that much rig uptime to fill — both are signposted in the UI. Display/observability
  only; the switching algorithm is untouched.

• Optional dashboard login (#8). A new dashboard.auth block puts a Caddy HTTP basic-auth prompt
  in front of the dashboard. It's opt-in and off by default — an empty dashboard.auth.password
  keeps today's behavior (no login), which is right for a private LAN appliance; set a password when
  the box is shared or reachable beyond the LAN. pithead bcrypt-hashes the password with the
  already-pinned Caddy image (caddy hash-password) and persists only the hash in .env
  (base64-encoded so bcrypt's $ doesn't spam compose interpolation warnings) — the plaintext lives
  solely in your owner-only config.json. A sha256 fingerprint of the plaintext keeps the hash
  stable across apply runs (re-hashed only when the password actually changes, so the Caddyfile
  doesn't churn). The username/password are validated before render, the secret is never echoed
  in the change preview, and apply warns if a password is set without dashboard.secure: true
  (basic-auth is cleartext over plain HTTP). Documented in
  `docs/configu...

⚠️ Superseded by v1.0.1 — do not use v1.0.0

v1.0.0's published images were arm64-only (built on an Apple-Silicon host) and won't run on x86_64 servers, and its install bundle was incomplete (missing monerod's config template). It was never installable.

v1.0.1 is the first installable release — identical features, built for linux/amd64 and packaged correctly. Please install that instead.

[1.0.0] - 2026年06月13日

First stable release.

Bundled, SHA-pinned upstream components: P2Pool v4.16, Monero v0.18.5.0, XMRig-proxy
6.26.0, Tari/minotari_node v5.3.1-mainnet, Caddy 2.11.4, docker-socket-proxy v0.4.2.
The exact image digests for each release ship in the GitHub Release's ingredients manifest.

monerod follows P2Pool v4.16's recommendations where they're compatible with the Tor-first model:
in-peers=64 (the inbound/open-files cap) is honored exactly, and the optional clearnet initial sync
(#183) runs monerod as a clearnet node should — out-peers=32 + P2Pool's recommended priority nodes
(p2pmd.xmrvsbeast.com, nodes.hashvault.pro) for that window. The DNS-based recommendations
(priority hostnames, DNS blocklist/checkpointing) stay off in Tor mode — they leak clearnet DNS
(#161) — with monerod's compiled-in checkpoints as the substitute. ./pithead doctor now also checks
that the system clock is NTP-synchronized (clock skew gets shares/blocks rejected), per P2Pool's
"synchronize your clock before mining" guidance.

Install / Upgrade

New install — clone the repo (or download the pithead-v1.0.0.tar.gz install bundle from the GitHub Release's assets) and follow the quickstart (./pithead setup).

Upgrade an existing (source) checkout:

git pull
./pithead upgrade

./pithead upgrade re-renders the generated config itself — the P2Pool v4.16 monerod settings (out-peers, the clearnet-window priority nodes) and the new doctor clock check are picked up automatically — then rebuilds and recreates only the containers that changed. No separate ./pithead apply is needed for this release, and your config.json plus preserved secrets (Tor onions, RPC credentials, proxy token) are kept untouched. Run ./pithead apply only when you edit config.json — e.g. to opt into the new, default-off clearnet initial sync. Verify afterwards with ./pithead status and ./pithead doctor.

See docs/operations.md for the full lifecycle reference.

Added

• Optional clearnet initial sync (#183). A default-off, per-component opt-in
  (monero.clearnet_initial_sync / tari.clearnet_initial_sync) that lets a node do its one-time
  initial block download over clearnet — much faster than over bandwidth-capped Tor circuits, which
  can crawl at near-zero blocks/sec — then return to Tor for all ongoing operation. When on, Monero
  drops its Tor P2P proxy= (lowering out-peers 48 → 16) but keeps tx-proxy=tor, so
  transaction-origin privacy is preserved and wallets are never exposed; Tari switches its transport
  to TCP and re-enables the seeds.tari.com DNS seed (its onion peer_seeds are unreachable without
  Tor). The only exposure is node-existence — your host IP is visible to that chain's P2P network
  for the sync window. Privacy-first by construction: off by default, a ⚠ disruptive-change
  confirmation on apply, a persistent "CLEARNET INITIAL SYNC ACTIVE — node IP exposed" banner in
  status/up, a doctor warning (and a green "Tor-only" check when off), and a matching warning in
  the monerod container logs — so a node is never silently left on clearnet. Exposed in
  config.advanced.example.json; documented with a full threat model in docs/privacy.md, plus
  docs/configuration.md, docs/getting-started.md, and docs/hardware.md.

• Automatic clearnet → Tor switch-back once synced (#234). The clearnet initial sync (above) no
  longer needs a manual flip back. The dashboard watches each chain's sync state and, the first time
  a clearnet node reports fully synced, writes a persistent marker and restarts the daemon — which
  comes back up Tor-only and stays there across restarts, apply, and reboots (the marker, not
  the flag, is the source of truth, so a synced node can never be silently re-exposed). Monero and
  Tari transition independently. Fail-safe: the marker is persisted before the restart and a failed
  switch is retried, never leaving a node stranded on clearnet; the status/up banner and doctor
  warning clear themselves once a node is genuinely back on Tor. Re-arm a fresh clearnet sync by
  toggling the flag off and on. Mechanism: a shared clearnet-state dir (dashboard rw, monerod/tari
  ro) drives the daemon entrypoints' Tor-vs-clearnet decision; pithead always renders the canonical
  Tor config. Closes #234.

• Dashboard "new release available" badge (#224). The dashboard periodically checks GitHub for
  the latest Pithead release and, if it's newer than the running version, shows a header badge next to
  the version badge — "New release vX.Y.Z available ↗" — linking straight to the release page.
  Notify-only: it never updates anything; you upgrade with ./pithead upgrade on your own terms
  (the one-click upgrade is the separate #59). On by default because the check is routed over
  Tor (the same bridge SOCKS as the XvB fetch, socks5h so the DNS lookup goes through Tor too) —
  GitHub sees a Tor exit, not your IP, so it leaks nothing about you; it's cached hourly and fails
  silently offline. Set dashboard.check_for_updates: false to opt out. Documented in
  docs/configuration.md + docs/privacy.md.

• Release pipeline — scripts/release.sh (make release) (#44). A single entry point, run from
  the private build/test server, that cuts a versioned release end to end: preflight (clean tree,
  SemVer from VERSION, tag-not-already-released, resolve the component pins) → blocking test gate
  (make test + the #54 live integration matrix) → build the 5 first-party images with OCI labels +
  PITHEAD_RELEASE=1 → push to a staging :vX.Y.Z-rc.N tag and capture digests → smoke-verify the
  pushed images from the registry → promote by digest to :vX.Y.Z + :latest (no rebuild, so
  the release is bit-for-bit what was tested) → publish the GitHub Release with an ingredients
  manifest (promoted digests + upstream pins) and a pinned install bundle. Safe by construction:
  --dry-run previews the whole plan, it never starts the live stack on the build host, and it never
  prints the registry token. Images publish to ghcr.io/p2pool-starter-stack/pithead-*
  (override via PITHEAD_REGISTRY / PITHEAD_IMAGE_PREFIX). Release installs pull the published
  images — no local build: each compose service carries an image: .../pithead-<svc>:${STACK_VERSION}
  ref alongside build:, and pithead auto-selects the mode — a source checkout (Dockerfiles present)
  builds locally and tags :dev (--pull never); a release bundle (no Dockerfiles, just
  pithead+VERSION+compose+build/tari/) resolves STACK_VERSION from VERSION and pulls
  :vX.Y.Z (--pull missing). So a release is ./pithead setup with no compile wait.

• Chart hashrate-averaging-window toggle (#168). A new Avg control on the dashboard chart
  plots any of xmrig-proxy's five native averaging windows — 1m / 10m / 1h / 12h / 24h. It's
  separate from the existing time-Range buttons: Range sets how much time the x-axis spans, Avg
  sets how smooth each point is (short windows react to a rig dropping/joining within a poll or two;
  long windows show the underlying trend). 10m is the default, so the chart is unchanged unless
  you switch — and the choice persists across reloads. Every option plots a true average for its
  window (the old headline "15m" was really the proxy's 10m relabeled; that's gone). All five windows
  are now captured per poll and persisted in their own history columns (additive migration, so
  existing databases upgrade in place); per-window history is forward-only, and the 12h/24h
  averages need that much rig uptime to fill — both are signposted in the UI. Display/observability
  only; the switching algorithm is untouched.

• Optional dashboard login (#8). A new dashboard.auth block puts a Caddy HTTP basic-auth prompt
  in front of the dashboard. It's opt-in and off by default — an empty dashboard.auth.password
  keeps today's behavior (no login), which is right for a private LAN appliance; set a password when
  the box is shared or reachable beyond the LAN. pithead bcrypt-hashes the password with the
  already-pinned Caddy image (caddy hash-password) and persists only the hash in .env
  (base64-encoded so bcrypt's $ doesn't spam compose interpolation warnings) — the plaintext lives
  solely in your owner-only config.json. A sha256 fingerprint of the plaintext keeps the hash
  stable across apply runs (re-hashed only when the password actually changes, so the Caddyfile
  doesn't churn). The username/password are validated before render, the secret is never echoed
  in the change preview, and apply warns if a password is set without dashboard.secure: true
  (basic-auth is cleartext over plain HTTP). Documented in
  docs/configuration.md#exposing-the-dashboard-safely.

• "Raffle Eligible" indicator on the dashboard (#158). A Hero-band + Simple-O...

v0.2: Algorithmic Yield Optimization & Dashboard 2.0

🚀 High-Level Summary

This release represents a complete architectural overhaul of the P2Pool Starter Stack. We have introduced Algorithmic Yield Optimization, a smart engine that intelligently switches hashrate between P2Pool and the XMRvsBeast bonus pool to maximize profitability based on donation tiers.

The update also features Dashboard 2.0, a completely rewritten monitoring interface with historical charting, persistence, and real-time system metrics, alongside a new CLI management tool and a dedicated Worker Provisioning Kit.

✨ Key Features

🧠 Algorithmic Switching Engine

• Yield Optimization: A new background service monitors total cluster hashrate and XMRvsBeast donation tiers.
• Dynamic Routing: Automatically switches the xmrig-proxy upstream target between P2Pool (default) and XMRvsBeast (bonus rounds) when specific hashrate thresholds are met.
• Seamless Operation: Workers connect to a single endpoint (Port 3333); the stack handles all routing logic transparently without requiring worker reconfiguration.

📊 Dashboard 2.0

• Complete Rewrite: Replaced the legacy status script with a robust Python/Aiohttp application.
• Persistence: Implemented SQLite storage to persist hashrate history and worker data across container restarts.
• Rich Visualizations:
  • Interactive charts showing P2Pool vs. XvB hashrate split and share submission events.
  • Real-time "Sync Mode" overlay for Monero/Tari synchronization status.
  • Detailed "Workers Alive" table with sorting and individual metrics.
• System Monitoring: Added tracking for Host CPU load, RAM usage, Disk usage, and HugePages status.

🛠️ New Management Tools

• Unified CLI (p2pool-starter-stack.sh): Replaces deploy.sh.
  • Start/Stop: ./p2pool-starter-stack.sh -s / -d
  • Upgrade: ./p2pool-starter-stack.sh -u (Rebuilds containers preserving config)
  • Logs: ./p2pool-starter-stack.sh -l
  • Reset: ./p2pool-starter-stack.sh -rd (Wipes dashboard data)
• Worker Provisioning Kit: A new worker/ directory containing scripts to automate XMRig compilation, kernel tuning (HugePages, MSR), and systemd setup on satellite miners.

🏗️ Architecture Changes

• XMRig Proxy: Added as a core service to aggregate worker connections.
• Docker Socket Proxy: Introduced a read-only sidecar for secure container monitoring.
• Tari gRPC: Dashboard now communicates directly with the Tari Base Node via gRPC.
• Network Mode: Dashboard uses network_mode: host for improved local discovery.

📦 Component Updates

• Monero: Updated to v0.18.4.5
• P2Pool: Updated to v4.13
• Tari: Updated to v5.2.1-mainnet
• Tor: Configuration refined for better hidden service isolation.

⚠️ Breaking Changes

• Script Deprecation: deploy.sh is removed. Use p2pool-starter-stack.sh for all operations.
• Worker Port: To utilize the algorithmic switching, point your workers to port 3333 (XMRig Proxy) instead of the P2Pool ports directly.

🆙 Upgrade Instructions

1. Stop the current stack:

   docker compose down

2. Pull the latest changes:

   git pull

3. Run the upgrade command:

   chmod +x p2pool-starter-stack.sh
   ./p2pool-starter-stack.sh -u

Initial Release of p2pool-starter-stack