UI mining Block height displying incorrectly..

[hammerhead3377]

Good insight! Let me update the draft to reflect this broader scope:

---

Public Pool UI Displaying Incorrect Block Height

Summary

Public Pool's web interface appears to be displaying incorrect block height information, even when no miners are actively connected. This seems to be a UI/display bug rather than an actual mining or template issue. Suspected to affect all local node setups.

Environment

• Bitcoin Node: Bitcoin KNOTS 29.2.knots20251010
• Setup: Both Datum and Public Pool connecting through the same KNOTS bitcoind
• Block in question: 922111
• Current network: Block 922112 in mempool

Suspected Scope

This issue likely affects all local node setups including:

• Docker deployments
• Umbrel nodes
• Datum mining infrastructure
• Bitcoin KNOTS nodes
• Potentially any self-hosted node configuration connecting to Public Pool

Issue Description

The Public Pool UI shows incorrect block attribution/height information. This persists even after disconnecting all miners, suggesting the issue is in the frontend display or database sync layer, not the mining backend.

Evidence

1. No stale shares reported - Network connectivity and block template delivery working correctly
2. Bitcoin KNOTS can only serve one block height template at a time - Both pools receive identical, correct data from the node
3. Datum displays correct information - Same node, different pool, correct display
4. Issue persists without miners connected - Rules out miner-side problems
5. Local node setup common factor - Self-hosted node configurations may share this bug

Expected Behavior

Public Pool UI should display the current block height being mined (matching what the connected Bitcoin node is serving).

Actual Behavior

Public Pool UI displays incorrect block height information that doesn't match:

• The actual block being mined
• What Datum reports from the same node
• The current blockchain tip

Technical Details

• Miner hash rate: 613.5 GH/s
• Session best difficulty: 644.65k
• Network difficulty: 155.97T
• Bitcoin KNOTS version: 29.2.knots20251010
• No stale shares or connectivity issues
• Clean operation otherwise

Hypothesis

The bug may be specific to how Public Pool's UI/API handles block height reporting from locally-hosted nodes versus cloud/pool-hosted infrastructure. Possible causes:

• API polling interval mismatch
• Cached block height data not updating
• Database sync lag between mining backend and frontend
• Local node RPC response parsing issue

Questions for Verification

1. Can other miners with local node setups (Docker/Umbrel/Datum/KNOTS) confirm this discrepancy?
2. Do miners using Public Pool's hosted infrastructure see the same issue?
3. Is this a known caching or database sync issue?
4. Where does the UI pull block height data from - could there be a stale API endpoint?

Impact

While this appears to be cosmetic (actual mining work is correct), it:

• Makes it impossible for miners to verify their work
• Could cause confusion about pool performance and block attribution
• May affect trust in pool statistics for self-hosted miners
• Could lead to false reports of pool issues

Request

Seeking confirmation from other miners running local node setups. If you're using Docker, Umbrel, Datum, or Bitcoin KNOTS with Public Pool, please check your UI and report whether you see similar block height discrepancies.

---

Better? This version:

• Emphasizes the local node setup pattern
• Lists specific environments likely affected
• Calls for peer confirmation from similar setups
• Notes your specific KNOTS version
• Frames it as potentially systemic to local node configs

TP

[remcoros]

I'm not seeing what you are seeing.

I'm using public-pool on StartOS connected to Core, on testnet4 at the moment and it shows the latest block.

Make sure you are using the latest versions of both public-pool and public-pool-ui.