I’ve been working on a personal project called CryptEX, where I implemented a full proof-of-work cryptocurrency system from scratch in C++.
This isn’t a token or a fork — it’s a ground-up implementation focused on how proof-of-work networks behave under unstable hash-rate conditions.
Instead of using fixed retarget intervals like Bitcoin (every 2016 blocks), this system adjusts difficulty per block using a hybrid model.
Key ideas behind the system:
SHA3-512 proof-of-work (full-width validation)
Per-block adaptive difficulty (LWMA + EMA + real-time easing)
Designed to handle sudden hash-rate spikes and drops
Lightweight PoW (ALU-bound, not memory-heavy, allowing participation from weaker nodes)
Custom P2P networking with peer discovery (LAN + seed)
UTXO-based validation with cumulative work chain selection
JSON-RPC interface + GUI frontend
Binary block storage (blk<height>.dat) with rebuild capability
Why I built this:
In many proof-of-work systems, especially those dominated by compute-heavy (ALU-intensive) mining, instability can arise from hash-rate volatility, where mining power temporarily spikes and then drops.
This typically results in:
- rapid increases in difficulty when miners join
- difficulty remaining too high after they leave
- stalled chains
- delayed confirmations
- unstable recovery
Traditional systems (like Bitcoin) adjust slowly, which makes this spike → drop cycle difficult to handle.
At the same time, many proof-of-work systems rely on memory-heavy algorithms, which can make participation difficult for weaker nodes and limit accessibility.
This project explores a different approach:
Current behavior:
Block times vary (~5–30 seconds depending on active miners)
Difficulty reacts quickly when nodes join or leave
Nodes converge on the same chain using cumulative work
Important note:
This is an experimental system, not production-ready or intended as a financial asset.
I’m sharing it mainly to discuss:
stability of per-block difficulty adjustment
tradeoffs vs fixed retarget intervals
behavior under extreme hash-rate changes
design tradeoffs between ALU-bound and memory-hard PoW
GitHub:
https://github.com/Anonymous137-sudo/CryptEX_Core
Whitepaper
https://github.com/Anonymous137-sudo/CryptEX_Core/blob/main/WHITEPAPER.pdf
CryptEX: A C++ SHA3-512 Proof-of-Work System with Per-Block Adaptive Difficulty for Hash-Rate Volatility
byu/Adventurous_Chef2225 inCryptoTechnology
Posted by Adventurous_Chef2225
1 Comment
I’m particularly interested in how people evaluate the stability of per-block difficulty adjustment under oscillating hash-rate conditions.
In this implementation, the goal is to respond quickly to both upward and downward hash-rate changes, especially in scenarios where short-lived bursts of compute (e.g. opportunistic mining) temporarily push difficulty up.
One concern I’ve been thinking about is whether a hybrid approach (LWMA + EMA + real-time easing) introduces second-order oscillations or feedback instability under noisy conditions.
For example:
* rapid hash-rate spike → difficulty overshoots
* miners leave → difficulty drops aggressively
* potential for oscillatory behavior if not damped correctly
In contrast, fixed-interval systems avoid oscillation but suffer from delayed recovery.
Curious how others would approach this tradeoff:
>