What happens
pithead validates monero.wallet_address by shape only (95 chars, leading 4, address-type prefix — the #250 gate). A well-formed but checksum-invalid address sails through validation and the wizard, and p2pool then dies on it at startup — not with a refusal, with a signal:
docker run --rm --entrypoint /bin/sh ghcr.io/p2pool-starter-stack/pithead-p2pool:v1.16.0 \
-c 'p2pool --mini --wallet 4AAAA...(95 chars) --host 127.0.0.1; echo exit=$?'
exit=134 # SIGABRT, 'Aborted (core dumped)'
On the appliance (KVM battery, provision phase, RC20/develop-v2) the same address produced Exited (139) (SIGSEGV) and, with restart: unless-stopped, a quiet crash-loop:
p2pool Exited (139) 3 minutes ago
xmrig-proxy Exited (0) 3 minutes ago # SIGTERM — lost its upstream
Everything else stays green: caddy serves, the dashboard answers 401, the built-in miner's unit is active. The operator sees a healthy box that will never mine and is never told why. (A control run with a checksum-valid address: p2pool starts and retries its node normally.)
Why it matters
A single mistyped character in an otherwise well-shaped address is exactly this case. The #250 gate exists because a wrong address 'mines but is never paid, silently' — this is the same failure mode one step earlier, and the crash-loop is just as silent.
Suggested direction
Found by
The tier-4 KVM battery's provision-phase local-miner leg (#796/#812): its dummy harness wallet (4 + 94×A) is precisely a well-formed, checksum-invalid address, so the 'accepted share' assertion could never pass. The harness is switching to a checksum-valid address; this issue is the product half.
🤖 Generated with Claude Code
What happens
pitheadvalidatesmonero.wallet_addressby shape only (95 chars, leading 4, address-type prefix — the #250 gate). A well-formed but checksum-invalid address sails through validation and the wizard, and p2pool then dies on it at startup — not with a refusal, with a signal:On the appliance (KVM battery, provision phase, RC20/develop-v2) the same address produced
Exited (139)(SIGSEGV) and, withrestart: unless-stopped, a quiet crash-loop:Everything else stays green: caddy serves, the dashboard answers 401, the built-in miner's unit is active. The operator sees a healthy box that will never mine and is never told why. (A control run with a checksum-valid address: p2pool starts and retries its node normally.)
Why it matters
A single mistyped character in an otherwise well-shaped address is exactly this case. The #250 gate exists because a wrong address 'mines but is never paid, silently' — this is the same failure mode one step earlier, and the crash-loop is just as silent.
Suggested direction
Found by
The tier-4 KVM battery's provision-phase local-miner leg (#796/#812): its dummy harness wallet (
4+ 94×A) is precisely a well-formed, checksum-invalid address, so the 'accepted share' assertion could never pass. The harness is switching to a checksum-valid address; this issue is the product half.🤖 Generated with Claude Code