How the Peer Probe System Prevents Cheating

← Back to Blog

Introduction

Proof-of-Energy mining requires an honest answer to a hard question: is this miner actually burning the energy they claim? Traditional Proof-of-Work avoids the question entirely — energy expenditure is implicit in the hash rate, and the protocol never asks how the work was done. Wattcoin faces a different problem: contributions are proportional to each machine's calibrated power curve, so the network must independently verify that each miner is running the hardware they say they are, that it is actually computing, and that it is computing at the expected speed.

The peer probe system is the mechanism that answers these questions. Every miner on the network periodically receives a computational challenge — a probe — from multiple peer coordinators. The probe must be solved locally and the result submitted within a strict time window. The outcome determines the miner's trust score, which scales their mining contribution from 20 % to 100 % of their hardware's rated power.

This post is a technical walkthrough of how the probe system works, what attacks it prevents, and where its limits are.

Probe Types

A probe is a deterministic computational workload matched to the miner's declared hardware capability. There are currently four types:

• CPU probe — a fixed-duration integer hash-chain loop (1000 ms). The worker runs for the full duration and counts iterations. The coordinator computes throughput as iterations / vdfTimingMs and verifies the proof hash against its own computation. A mismatch is conclusive evidence of tampering.
• GPU PoW probe — a native binary computes a nonce search where the XOR-shift hash must meet a difficulty target. Each GPU in a multi-card rig searches a unique nonce space partitioned by device index. The proof is self-authenticating — the nonce itself proves work was done — and the coordinator verifies server-side without needing a GPU.
• ASIC probe — the coordinator issues a cryptographic liveness challenge (random prevHash) that the worker injects into the local stratum pool. The ASIC must mine valid X11 shares containing the challenge; the coordinator cryptographically verifies each share and checks that the share production rate matches the declared hashrate.

Hardware Attestation — You Cannot Lie About What You Have

Before any probe is issued, every miner must pass a hardware verification step during benchmark. The renderer sends its hardware strings (CPU model, GPU model, device type) to the main process, which independently verifies them:

• The CPU model is read from os.cpus()[0].model — the operating system kernel, not the renderer, decides what CPU is installed. Any mismatch triggers a −20 trust penalty and forces a power curve re-benchmark.
• The GPU model is verified through two independent channels: the OS-level resolveOsHardwareIdentity() function and, on Windows, the native gpu-miner.exe binary that reports the DXGI adapter name. A power curve benchmark is required to establish the machine's actual power fingerprint.
• Device type (desktop vs. laptop) is cross-checked. A renderer claiming "desktop" while the OS reports "laptop" triggers a clamp to the laptop's power ceiling.
• Virtual machines are blocked entirely — VM-based mining cannot attest hardware identity to the required standard of proof.

After identity verification, a power curve benchmark measures the machine's actual power draw at 10 load levels (10%–100%) using hardware power sensors (RAPL, EMI, NVML). This creates a per-machine power fingerprint that replaces generic TDP lookups. The power curve is HMAC-signed to prevent tampering. At each probe, the miner's configured load indexes into the curve to determine the active power draw, and the trust factor (0.2 to 1.0) is applied at contribution time.

Proof Hash Chain — Sequential Computation Required

Probes are chained together cryptographically. Each probe's seed is derived from the proof hash of the previous probe in the chain. This means a miner cannot pre-compute probes or skip ahead — the seed for the next probe is unknown until the current probe's result is produced. If the chain is broken (e.g., the probe times out and the worker resets to null), the next seed is a fresh random value with no link to prior work.

VDF Proof-of-Time

Every peer probe is paired with a Verifiable Delay Function (VDF) — a cryptographic proof that a minimum amount of sequential computation time has elapsed. The VDF replaces the coordinator's wall clock as the authoritative timing source, making it impossible for a worker to lie about how long a probe took.

The worker starts the VDF computation before the benchmark workload so both run in parallel. The VDF runs in the main process while CPU, GPU, or ASIC work runs in the renderer or hardware driver. Total probe time = max(benchmark, VDF).

challenge = SHA-256(probeId ‖ workerId ‖ chainIndex)
proof = 2000 sequential squarings, 512-bit discriminant
verify ≈ 1–2 ms  |  solve ≈ 1 s  |  cannot be parallelized

The VDF input binds the proof to a specific probe, worker, and chain position — preventing pre-computation or replay across probes. Without a valid VDF proof, the probe fails with vdf_missing. The coordinator uses the worker's measured VDF timing (vdfTimingMs) as the authoritative time for energy accumulation and throughput calculations.

For CPU probes, the coordinator computes throughput as iterations / vdfTimingMs. Because the VDF proves that at least the stated time elapsed, a worker cannot inflate its ops/sec by fabricating iteration counts — the math does not work if the denominator is cryptographically enforced.

Trust Score — How Probes Drive Mining Power

Every probe result updates the miner's trust score, which scales their contribution linearly:

trustFactor = 0.2 + (trustScore / 100) × 0.8
maxDeltaWh = (powerCurveMaxW × trustFactor × loadFactor × 0.5) / 3600

The loadFactor is derived from the miner's hardware load slider setting (Math.min(1, Math.max(0.1, loadPercent / 100))). If the miner sets load to 50 %, the loadFactor is 0.5, halving the per-tick contribution ceiling. This gives the server-side authoritative enforcement over the load slider — server-side energy verification ensures claimed load matches actual computational activity.

At trust score 0, the miner contributes at only 20 % of their calibrated power. At trust score 100, they contribute at 100 %. The score moves as follows:

• +1 for 25 consecutive verified probes with no issues
• −1 per failed probe (mismatch or timing violation)
• −3 per proof mismatch (strong evidence of cheating)
• −1 additional if the last 50 probes have a failure rate above 30 %
• −20 for a hardware identity mismatch (detected at benchmark time)

Multi-Coordinator Cross-Attestation

A single malicious coordinator could issue easy probes or accept fake results. To prevent this, every miner connects to multiple coordinators simultaneously, and each independently issues probes. At settlement time, the protocol checks that at least 3 verifier attestations exist for the claimed chain index — requiring a majority of coordinators to collude before the protection is bypassed.

Connections are maintained via persistent WebSocket channels. If a coordinator goes offline, only that slot is replaced, leaving the other connections intact. This design makes the probe stream resilient — a miner receives probes from multiple coordinators at random intervals throughout each round.

Network Outlier Detection

Even if a miner passes individual probes, an anomalously high power-to-CPU ratio compared to the rest of the network is flagged. Each miner's stats are recorded in a network-wide histogram. If a miner's ratio deviates more than 3 standard deviations from the mean of all other miners, a flag is raised at benchmark time. This catches cases where a miner declares a reasonable CPU model but inflates the power curve beyond what the benchmark-implied power would suggest.

How Protections Work Together

Computational proof verification

The coordinator independently re-computes CPU proofs and cryptographically verifies GPU-PoW nonces and ASIC X11 shares, so any fabricated result is detected immediately.

Multi-channel hardware attestation

OS-level CPU model, DXGI GPU model from the native binary, and device type cross-checks make it infeasible to claim a different chip than what is physically installed. Virtual machines are blocked entirely.

Chained seed derivation

Each probe's challenge derives from the previous probe's proof hash, so the next challenge is not known until the current probe is solved. No probe can be computed ahead of time.

Physical-machine-bound contributions

Contribution is bound to the physical machine's calibrated power curve rather than the number of worker identities, preventing identity multiplication from increasing mining power.

Summary

The peer probe system is a multi-layered attestation framework that makes it prohibitively expensive to cheat at Proof-of-Energy mining. VDF proof-of-time, computational proof verification, OS-level hardware identity checks, multi-coordinator cross-attestation, network outlier detection, and sliding-window trust scoring each address a different attack vector. No single layer is perfect, but together they raise the cost of cheating well beyond any possible reward.