/mining-status can overcount solved transactions compared to Prometheus and Explorer

[luislhl]

Problem

The transaction counters exposed by /mining-status do not appear to be reliable.

Observed behavior shows /mining-status overcounting solved transactions compared to both:

• the Prometheus txs_solved_total metrics, and
• the actual number of transactions visible in Explorer between the same comparison points.

At least in the observed samples, the Prometheus counters matched the real transaction count while /mining-status reported more solved transactions than actually happened.

Evidence

Example comparison window:

• Between 16:38:29 and 16:40:18, only 7 transactions were observed in Explorer.
• In the same window, /mining-status increased by:
  • cpuminer: 1033 -> 1035 (+2)
  • ccminer: 39 -> 47 (+8)
  • cgminer: 9 -> 9 (+0)
  • Total increase reported by /mining-status: 10
• In the same window, Prometheus increased by:
  • cpuminer: 1098.0 -> 1100.0 (+2)
  • unknown (corresponding to the fast miner observed here): 38.0 -> 43.0 (+5)
  • cgminer: 211.0 -> 211.0 (+0)
  • Total increase reported by Prometheus: 7

That Prometheus increase matches the transaction count observed in Explorer, while /mining-status overcounts.

Possible Cause

A likely explanation is that the local miner counter is incremented before the solution is definitively accepted as the unique winning solution.

In txstratum/protocol.py, the current flow appears to increment the miner-local transaction counter immediately after verify_pow() succeeds:

if obj.verify_pow():
    self.manager.submit_solution(self, job, obj.get_struct_nonce())
    if obj.is_block:
        self.blocks_found += 1
    else:
        self.txs_solved += 1

If a very fast miner submits multiple valid solutions for the same transaction before a new job is issued, the manager may reject later submissions because the transaction was already solved, but self.txs_solved may already have been incremented more than once.

This would explain why:

• the overcount is seen in /mining-status,
• the manager-level Prometheus metrics remain correct, and
• the effect is more visible on faster miners.

Expected Behavior

/mining-status should only count transactions that were actually accepted as solved, so its counters stay aligned with the authoritative manager-level metrics and with real transaction outcomes.