SChernykh/p2pool: decentralized Monero mining without a pool operator

P2Pool's place between centralized pools and Monero solo mining

P2Pool addresses a specific governance and custody problem in Monero mining. A centralized pool offers regular payouts and simple setup, but its operator controls the miner's unpaid hashrate and can influence which blocks the pool mines. Solo mining removes the pool operator, yet rewards are rare because an individual miner must find a block independently. P2Pool attempts to retain solo mining's lack of a pool administrator while creating a pool capable of distributing rewards more regularly.

The README describes P2Pool as permissionless because there is no authority deciding who may participate. It also describes the payment path as trustless because there is no pool wallet holding miners' funds. Pool blocks pay miners directly, and the administrator who operates a conventional mining pool has no equivalent unilateral role in P2Pool.

This distinction does not make P2Pool independent of Monero node operation. A synced Monero node remains required, while P2Pool adds its own node and sidechain processes. The practical comparison is therefore between three operating models: a conventional pool that minimizes infrastructure for the miner, solo mining that minimizes pool dependency, and P2Pool that adds components in exchange for decentralized regular payouts.

How P2Pool share accounting reaches Monero payouts

P2Pool uses a separate blockchain that is merge-mined with Monero. Mining through P2Pool first produces pool shares on that sidechain. A share remains eligible for a payout while it stays inside the PPLNS window, which is described as holding up to 2160 pool blocks and as covering approximately six hours by default.

When the P2Pool network finds a Monero block, miners with at least one share in the PPLNS window can receive a payout. The Monero block reward is divided among the miner wallets represented in that window. Each miner's portion is proportional to the combined difficulty of its eligible shares rather than to a centrally calculated pool balance.

The defaults are a 10-second P2Pool block time and an automatically adjustable window of up to 2160 blocks. The stated minimum payout is the Monero block reward divided by 2160, approximately 0.00027 XMR. Both the window and block time are configurable, which gives operators control over the expected trade-off between payout size and payout frequency.

The README also states that uncle blocks are supported so shares are accounted for rather than becoming apparent orphans. This mechanism matters because the P2Pool network may construct blocks that do not become the selected chain. Recognizing those blocks helps preserve share eligibility, although it does not guarantee that every share produces a direct payout.

P2Pool hashrate and bad-luck limits on payment frequency

The most important limitation is mathematical rather than administrative. The README states that if P2Pool does not have enough hashrate to find Monero blocks more often than once every six hours on average, approximately 15 MH/s in the documented example, some shares can leave the PPLNS window without receiving a payout. Even above that level, unfavorable block-finding luck can produce the same outcome for an individual share.

The README says that over time, other shares can receive multiple payouts, bringing the average result closer to conventional pool mining. That is an aggregate expectation, not a promise that every share is paid separately or that every miner receives a payment on a fixed schedule. The approximately 0.00027 XMR figure is a minimum payout parameter, not a guaranteed payment for every mining interval.

P2Pool also permits failure handling across its node topology. Multiple P2Pool nodes can mine to the same wallet, and each P2Pool node can use multiple Monero nodes and switch when an issue is detected. The documentation describes this as highly reliable configuration, but it also adds setup and monitoring work. Redundancy reduces a single-node dependency, yet it does not remove the need to keep the Monero node synchronized and the P2Pool nodes connected.

Building P2Pool with the repository Dockerfile

The README links to build instructions and includes a Dockerfile for the build path. It does include a Dockerfile, so the documented build path can be inspected there. The first stage starts from `debian:12-slim`, installs the C++ build dependencies, copies the repository into `/usr/src/p2pool`, initializes Git submodules, and builds through CMake and Make.

The dependency list gives a concrete indication of the native requirements: `libuv1-dev`, `libzmq3-dev`, `libsodium-dev`, `libpgm-dev`, `libnorm-dev`, `libgss-dev`, and `libcurl4-openssl-dev`. The second image retains only the `/p2pool` binary and selected runtime libraries. It creates an unprivileged `p2pool` user, makes `/home/p2pool/.p2pool` writable by that account, and declares ports 3333, 37889, and 37888.

The Dockerfile does not name a published image, so it would be misleading to provide an undocumented pull command. It also does not include a `monerod` binary. A containerized P2Pool process therefore still depends on access to a compatible, synchronized Monero node. The repository has `docker-compose/` entries.

Preparing monerod and selecting a P2Pool sidechain

The first operational step comes from the README: obtain an official Monero binary, start `monerod` on the machine, and wait until the node is fully synchronized. The required Monero software version is v0.18.0.0 or newer, with v0.18.4.6 or newer recommended. No exact `monerod` launch command is documented here.

After the Monero node is ready, the P2Pool process needs the wallet destination. A primary wallet address begins with `4` and can be supplied as the wallet. A miner using a subaddress must provide both the primary address and the `8` subaddress. The documented command-line parameters are shown here:

--wallet
--subaddress

The README also documents `--mini` and `--nano` as P2Pool command-line parameters for selecting the corresponding sidechain. They cannot be used together. It states that `--mini` changes the P2P port to 37888.

--mini
--nano

These are parameter names, not complete launch commands. The README excerpt does not provide the syntax for combining them with a binary path, wallet address, or Monero RPC endpoint. Users must consult the complete mining instructions for the valid invocation. This distinction matters because reproducing isolated flags without their required values would not produce a working first mining session.

P2Pool maintenance, upgrades, and operational boundaries

P2Pool must be kept compatible with Monero network upgrades. The README states that both Monero and P2Pool should be updated to the latest available versions when required releases appear. Its support table maps Monero protocol versions v15 and v16 to Monero v0.18.0.0 or newer and P2Pool v4.0 or newer, with Monero v0.18.4.6 or newer recommended.

Repository activity is recent: the last push was on 2026-10-14. Releases listed for the project include v5.0-beta on 2026-10-01, v4.18.1 on 2026-09-22, and v4.18 on 2026-08-05. The presence of a beta release also means operators should distinguish the beta line from the listed patch and minor releases rather than assuming every version has the same stability or compatibility profile.

The project is licensed under GPL-3.0. That matters when modifying or redistributing the software because the license contains source-availability and notice obligations, although this review does not provide legal interpretation. Operationally, upgrade cost comes from coordinating P2Pool with Monero. An outdated P2Pool release, an outdated `monerod`, or a node that has not finished synchronization can prevent mining as intended.

P2Pool supports private pools, TOR, and I2P according to the README. Those capabilities address access and isolation needs, but their exact configuration steps are not documented here. Private pools are password protected, and dedicated documents exist for TOR and I2P. Their presence broadens the project's deployment choices, but it does not remove the basic requirement for compatible Monero node infrastructure.

Editorial conclusion

P2Pool fits miners who want regular payouts while keeping block rewards outside the custody of a conventional pool operator, and who are prepared to operate or connect to both monerod and P2Pool. It is a poor fit for someone seeking a single-command mining setup or predictable payment for every submitted share. Before adoption, verify compatibility with the latest Monero network version, confirm that the required monerod node is fully synchronized, and calculate whether the local P2Pool sidechain has enough expected hashrate for the intended payout frequency.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. SChernykh/p2pool on GitHub