consensus: Harden protocol for low-hashpower network conditions

[augchan42]

Summary

Community feedback from Telegram has identified several issues that occur when BTQ Core operates at low hashpower, where Bitcoin's statistical assumptions collapse. This issue tracks protocol-level hardening recommendations.

Current Behavior

At low hashpower, users observe:

• "Time travel" blocks with erratic timestamps
• Difficulty "cliffs" when miners join/leave
• Explorer graphs showing meaningless data
• Block times that don't match expectations

Root Cause Analysis

BTQ Core inherits Bitcoin's consensus parameters, which assume massive parallelism and the law of large numbers. At low hashpower, these assumptions break down.

---

Recommended Fixes

1. Clamp Timestamps More Tightly (HIGH PRIORITY)

Current: MAX_FUTURE_BLOCK_TIME = 2 hours (src/chain.h:24)

Problem: A 2-hour future drift is too permissive. A single miner with a bad clock dominates timestamp behavior.

Recommended: Reduce to 2-5 minutes:

static constexpr int64_t MAX_FUTURE_BLOCK_TIME = 5 * 60;  // 5 minutes

Impact: Eliminates ~80% of timestamp "glitch" reports.

---

2. Implement Per-Block Difficulty Adjustment (HIGH PRIORITY)

Current: Traditional 10,080-block retargeting (src/pow.cpp)

• Difficulty stays constant for ~1 week
• 1/4x to 4x adjustment limits

Problem:

• Creates difficulty "cliffs" when hashpower fluctuates
• Slow recovery from hash spikes
• Explorer difficulty graphs look "deranged"

Recommended: Implement LWMA (Linear Weighted Moving Average) or ASERT

Options:

• LWMA-3: Widely used by small PoW chains, battle-tested
• ASERT: Very stable, used by Bitcoin Cash

Benefits:

• No difficulty cliffs
• Difficulty responds smoothly to hashrate changes
• Per-block adjustment instead of weekly

---

3. Add Minimum Difficulty Floor (MEDIUM PRIORITY)

Current: Only floor is powLimit (absolute minimum difficulty)

Problem: Difficulty can collapse to near-zero, enabling:

• Instant block spam
• Timestamp manipulation becoming profitable
• Hashrate graphs becoming meaningless

Recommended: Add floor relative to genesis difficulty:

// Example: 1e-6 of genesis difficulty
target_difficulty >= genesis_difficulty / 1000000

---

4. Soft Minimum Block Interval (LOW PRIORITY)

Current: No enforcement beyond median time past. Blocks can arrive arbitrarily fast.

Problem: Bursty mining creates erratic block times that confuse users and explorers.

Recommended approach: Rather than hard rejection, nudge difficulty faster for rapid blocks:

• Blocks < 30% of target spacing are valid
• But difficulty increases more aggressively for the next period

---

Files to Modify

File	Change
src/chain.h:24	Reduce MAX_FUTURE_BLOCK_TIME
src/pow.cpp	Replace difficulty algorithm with LWMA/ASERT
src/consensus/params.h	Add new params (e.g., nLwmaAveragingWindow)
src/kernel/chainparams.cpp	Set new difficulty adjustment parameters

---

Additional Context

These issues are not bugs—they're what happens when systems built for crowds are operated by a handful of actors. The fixes above replace statistical assumptions with explicit constraints.

Reference Implementations

• LWMA: LWMA difficulty algorithm zawy12/difficulty-algorithms#3
• ASERT: https://reference.cash/protocol/forks/2020-11-15-asert

Related

• Block timing was recently reduced from 10 minutes to 1 minute (commit dd96e0c)
• Dilithium signatures require larger blocks, making UTXO consolidation important

[augchan42]