Port miner113's RX_DRAGONX mining model into the RX_HUSH path so DragonX
mining is identical in solo and pool mode:
- CpuWorker: filter EVERY hash on SHA256D(header + RandomX solution) (the
block-bearing pow-hash) instead of the RandomX hash; submit the full
32-byte nonce + rx_hash. Removes the fragile pool-mode dual-check that
was dropping ~half of block candidates.
- Job: 32-byte nonce for RX_HUSH in pool mode too (was solo-only).
- JobResult: populate nonceBytes() on the standard 4-byte path.
- Client: submit a variable-width nonce (32-byte for DragonX) with a
dynamically laid-out temp buffer.
Effect: shares and blocks use one metric, so the pool receives every block
candidate (no under-submission gap) and the hashrate is block-relevant.
Rebrand to drg-xmrig (version.h, build.sh, package.json, README) + add
PROTOCOL.md wire spec.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Pool sends block_target (full 256-bit network target) with each job.
Miner checks SHA256D(header + RandomX solution) for every hash against
the block target, enabling block detection at full hashrate instead of
only on submitted shares.
- Switch from full-block to header-only (140-byte) RandomX input
- Add 32-byte SoloNonce system for solo mining mode
- Compute proper difficulty target from compact bits field
- Add SHA256D dual-hash PoW check in CpuWorker for solo mining
- Raise RandomX dataset/scratchpad limits to 4GB/4MB
- Use standard RandomX share filtering in pool (stratum) mode
- Uses scratchpad interleaving to access only the closest L3 slice from each CPU core.
- Also activates MSR mod for cn-heavy because CPU prefetchers get confused with interleaving
- 7-8% speedup on Zen3
- Use only steady timestamp counters to guarantee correctness
- CPU backend: directly measure total hashrate using raw hash counters from each thread; update data more often on ARM CPUs because they're slower
- GPU backends: directly measure total hashrate too, but use interpolator with 4 second lag to fix variance from batches of hashes
Total hashrate is now measured directly (realtime for CPU, 4 seconds lag for GPU), so it might differ a bit from the sum of all thread hashrates because data points are taken at different moments in time.
Overhead is reduced a lot since it doesn't have to go through all threads to calculate max total hashrate on every timer tick (2 times a second).
