Display aggregated stratum client share stats in solo (non-pooled) mining mode

[justinfilip]

Problem

When running DATUM Gateway without a pool configured, the "Shares Accepted" and "Shares Rejected" counters on the web dashboard always display 0, as there is no pool to track shares against. This makes it impossible to monitor mining activity via the gateway when not connected to a pool.

Community Discussion

https://x.com/innerhat/status/1979236476652261388

I'm not the only one who can see the confusion around the feature, and I can do something to help.

Solution

This PR mirrors stratum client share submissions into the existing pool share counters when no pool is active/configured, allowing miners to see their mining activity on the dashboard regardless of pool configuration.

Dashboard behavior:

• Pool configured/active: Shows pool share statistics (existing behavior)
• No pool configured/active: Shows local stratum client share statistics mirrored into pool counters (new behavior)

Note: DATUM always constructs block templates from your own Bitcoin node in all configurations. The difference is whether shares are accounted for by a pool or tracked locally.

Changes

Modified Files

• src/datum_stratum.c - Added mirroring logic to increment pool counters when no pool is active
• src/datum_stratum.h - Removed stratum_client_* counter declarations
• src/datum_api.c - Simplified dashboard display logic
• README.md - Updated documentation to clarify share statistics behavior

Modifications

• When no pool is active/configured, mirror local share submissions into existing datum_accepted_share_count/datum_rejected_share_count counters
• Use datum_protocol_is_active() and datum_pool_host to determine if pool is active
• Track all share acceptance/rejection paths (stale-prevblock, time-too-old/new, high-hash, stale-by-time, duplicate)
• Update README to clarify that dashboard prefers pool stats when pool is active, local stats when not

Performance Impact

Atomic Operations Cost

Operation	CPU Cycles	Notes
__atomic_add_fetch() (RELAXED)	~5-10	Per atomic operation
2 atomic ops per share	~10-20	Count + diff increment
Regular addition	~1	Baseline comparison
Added overhead	~18	Per share (no pool only)

Context

• SHA256 double hash (share validation): ~100,000+ cycles
• Network latency: millions of cycles
• Our overhead: 0.01-0.02% of validation time

Real-World Impact

Aspect	Impact
Template delivery	NO CHANGE (separate thread)
Share latency	+0.01-0.02% (unmeasurable, no pool only)
Mining efficiency	NO CHANGE
Block propagation	NO CHANGE

Conclusion

The atomic increments only execute when no pool is active, adding a few nanoseconds per submitted share on the gateway. Template generation and delivery are completely unaffected (separate thread).

Testing

Tested with:

• DATUM Gateway without pool configured
• Connected ASIC miner submitting shares
• Share counters increment correctly for accepted shares
• Web dashboard displays accurate statistics
• No performance degradation observed

Could not test:

• Share counters for rejected shares (stale, duplicate, high hash, time errors), but logic is implemented for all rejection paths

Benefits

• Miners can now monitor their mining activity in real-time regardless of pool configuration
• Better visibility into miner performance and configuration issues
• Reuses existing pool counter variables (no new state)
• No behavior change when pool is configured
• Zero measurable performance impact

[justinfilip]

Addressed all points and updated the PR description, as well as the README. Re-tested and verified share counts are working.