Problem
When solo mining with Public Pool, the miner has no way to verify what is actually being mined. Specifically:
-
Coinbase payout address is invisible. The miner configures their BTC address as the stratum username, but the coinbase transaction is constructed server-side by Public Pool. The miner receives coinb1 and coinb2 as opaque hex in mining.notify — AxeOS and similar firmwares do not decode or display this. There is currently no way for a miner to confirm the coinbase actually pays to their address without intercepting and manually decoding Stratum messages.
-
Template contents are opaque. Stratum V1 reduces the full block template to merkle branches — the miner never sees the transactions. While a self-hosted operator can query getblocktemplate from Bitcoin Core directly, Public Pool's own API (/api/pool) only exposes operational stats (hashrate, workers, shares, found blocks), not the template being served.
For a project built around sovereignty and trust-minimization, this is a gap. A miner should be able to verify what they are mining on.
Proposed solution
Add a new API endpoint (e.g. /api/template/current) that exposes a read-only summary of the current state. No new database tables or storage required — this data already exists in memory.
Coinbase details (most important)
- Output address (the address being paid to)
- Coinbase value (subsidy + fees, in satoshis)
- Pool tag / coinbase script text (e.g. "Public-Pool")
- Witness commitment (present / valid)
Template summary
- Transaction count
- Total fees (satoshis)
- Total weight and percentage of 4 MWU limit
- Fee rate stats (min / median / max sat/vB)
- Previous block hash and height being built on
- Timestamp of last template refresh
Why this matters
-
Trust verification for self-hosters: Even when you own the node and the pool, being able to confirm coinbase correctness through the API (rather than trusting the code path) is valuable defense-in-depth.
-
Transparency for hosted pool users: Miners pointing at public-pool.io currently trust that the pool constructs coinbases correctly. An API endpoint would make this verifiable.
-
Lightweight and non-breaking: The GBT response and constructed coinbase already live in memory. This is a read-only summary — no changes to the mining logic, no new dependencies, no storage overhead.
-
Aligns with Public Pool's ethos: The project already differentiates itself through open source code, zero fees, and self-hostability. Exposing what the pool is actually mining would be a natural extension of that transparency.
Context
Related tools like mempool.space and miningpool.observer provide deep template and block analysis, but they operate at the network level. This request is about giving individual miners visibility into their own pool's behavior through the existing Public Pool API.
Problem
When solo mining with Public Pool, the miner has no way to verify what is actually being mined. Specifically:
Coinbase payout address is invisible. The miner configures their BTC address as the stratum username, but the coinbase transaction is constructed server-side by Public Pool. The miner receives
coinb1andcoinb2as opaque hex inmining.notify— AxeOS and similar firmwares do not decode or display this. There is currently no way for a miner to confirm the coinbase actually pays to their address without intercepting and manually decoding Stratum messages.Template contents are opaque. Stratum V1 reduces the full block template to merkle branches — the miner never sees the transactions. While a self-hosted operator can query
getblocktemplatefrom Bitcoin Core directly, Public Pool's own API (/api/pool) only exposes operational stats (hashrate, workers, shares, found blocks), not the template being served.For a project built around sovereignty and trust-minimization, this is a gap. A miner should be able to verify what they are mining on.
Proposed solution
Add a new API endpoint (e.g.
/api/template/current) that exposes a read-only summary of the current state. No new database tables or storage required — this data already exists in memory.Coinbase details (most important)
Template summary
Why this matters
Trust verification for self-hosters: Even when you own the node and the pool, being able to confirm coinbase correctness through the API (rather than trusting the code path) is valuable defense-in-depth.
Transparency for hosted pool users: Miners pointing at
public-pool.iocurrently trust that the pool constructs coinbases correctly. An API endpoint would make this verifiable.Lightweight and non-breaking: The GBT response and constructed coinbase already live in memory. This is a read-only summary — no changes to the mining logic, no new dependencies, no storage overhead.
Aligns with Public Pool's ethos: The project already differentiates itself through open source code, zero fees, and self-hostability. Exposing what the pool is actually mining would be a natural extension of that transparency.
Context
Related tools like mempool.space and miningpool.observer provide deep template and block analysis, but they operate at the network level. This request is about giving individual miners visibility into their own pool's behavior through the existing Public Pool API.