Just how capable are AI coding agents? What started as a few curious questions ended up producing hardfork consensus changes designed to make Nerva’s algorithm more resistant to non-CPU miners:
https://github.com/R0BC0D3R/nerva/commit/ab285cfc5b589281f147cc339dbd7b05eb1bafc7

Enjoy

How is this project mining pool resistant?

Let me explore the codebase to find the pool resistance mechanisms.

Agent:Explore pool resistance mechanisms

In the Nerva cryptocurrency project at d:\Code\Crypto\Nerva\nerva, find all code and documentation related to mining pool resistance. Look for: solo mining enforcement, pool detection/blocking, algorithm design choices that prevent pooled mining (e.g. "one-cpu-one-vote", Cryptonight variants, DAA), any consensus rules or protocol-level restrictions against pools, and relevant comments or config. Search for terms like "pool", "solo", "asic", "RandomX", "CryptonightR", "one-cpu", "pool-resistant", "stratum". Report what you find with file paths and line numbers. Thoroughness: very thorough.

Nerva’s pool resistance operates on multiple layers:

How Nerva is Mining Pool Resistant

1. Architectural Requirement (the core mechanism)

Each miner must hold a full copy of the blockchain. Traditional mining pools work by distributing work to miners who don’t run full nodes — Nerva’s PoW algorithm pulls parameters directly from blockchain data, so you can’t participate in mining without a full node. This makes the typical “pool server hands out work, collects shares” model architecturally impossible.

• src/cryptonote_core/blockchain.cpp — get_block_longhash() reads live chain data for PoW computation
• src/cryptonote_core/cryptonote_tx_utils.cpp:696 — v11+ algorithm calls db.get_cna_v2_data() / db.get_cna_v5_data() pulling chain-specific salt from the blockchain DB

2. Algorithm Randomization (makes work-splitting hard)

The CryptoNight variants use per-block randomized parameters derived from block height, nonce, and blockchain history:

• v10 (tx_utils.cpp:727-766): Mersenne Twister PRNG seeded from blockchain data produces randomized block sizes and 4 parameters (xx, yy, zz, ww) per block
• v11+ (tx_utils.cpp:687-725): HC128 stream cipher seeded from the blob hash drives per-block scratchpad layout
• Height-dependent iteration count: (height + 1) % 64 varies work per block — a pool can’t pre-compute or batch this

3. Memory-Hard Scratchpad

src/crypto/hash-ops.h:91-93 defines a 1 MB scratchpad (CN_SCRATCHPAD_MEMORY = 1048576). The sequential AES operations over this scratchpad:

• Prevent efficient GPU parallelization (each thread needs 1 MB of fast cache)
• Prevent ASIC optimization
• Favor standard CPUs with AES-NI

4. No Stratum / Pool Protocol

There is simply no Stratum server or pool share-accounting code anywhere in the codebase. The miner (src/cryptonote_basic/miner.cpp) supports only solo mining with an optional donation percentage — no multi-miner address aggregation.

5. Stated Design Intent

README.md:18-22 explicitly: “Each miner requires a copy of the blockchain, hence there is no support for pool mining.” This is enforced at the protocol level, not just policy.

In short: It’s not just a rule against pools — the PoW algorithm physically requires blockchain data that only a full node has, making pool-style work distribution impossible without each “pool member” running a full node (at which point they’re just solo mining anyway).

How does this compare to Monero’s RandomX algo?

This is a good comparison to make — the two algorithms share goals (CPU-friendly, ASIC/GPU-resistant) but take fundamentally different approaches.

Nerva CryptoNight Variants vs. Monero RandomX

Core Design Philosophy

How RandomX Works (the key difference)

RandomX generates a random program (roughly 256 instructions) from a seed derived from the block template hash, then JIT-compiles and executes it in a sandboxed VM. The 2 GB dataset is computed from the seed and kept in RAM; the 256 MB scratchpad is what each hash uses actively.

Critically: the seed is just the block hash prefix — no blockchain DB access required. A pool server can generate valid work units and hand them to miners who never touch the chain. This is why Monero has thriving pools.

How Nerva Differs

Nerva’s resistance is architectural rather than algorithmic:

• v11+ algorithm calls db.get_cna_v2_data() and db.get_cna_v5_data() (src/cryptonote_core/cryptonote_tx_utils.cpp:696-708) — these pull salt data from the live blockchain database, not just the block header
• A pool server cannot generate these parameters without running a full node, and if it does run a full node, each “pool member” still needs chain access to verify and submit — functionally collapsing back to solo mining

RandomX doesn’t have this property at all. It’s designed to be efficiently verifiable (light mode uses 256 MB) and distributable.

Trade-offs

RandomX is stronger as an ASIC/GPU deterrent — the 2 GB memory requirement and random program execution are much harder to optimize in hardware than Nerva’s 1 MB AES scratchpad. GPU farms can mine Nerva with some efficiency loss; RandomX’s branch-heavy random code punishes GPUs far more severely.

Nerva is stronger as a pool deterrent — RandomX does nothing to prevent pools; Nerva’s blockchain-data dependency makes pools architecturally impossible without each participant running a full node.

Nerva’s 1 MB scratchpad is a notable weakness relative to RandomX. The smaller scratchpad means modern CPUs with large L2/L3 caches handle it easily, but GPUs with high bandwidth and many cores can still parallelize it more than RandomX allows.

Summary

RandomX solves “how do we keep ASICs and GPUs out?” better. Nerva solves “how do we keep pools out?” in a way RandomX never attempted. They’re complementary approaches to different problems — Nerva sacrifices pool-compatibility resistance for pool impossibility, at the cost of a less aggressive memory footprint than RandomX.

What would you change to make Nerva’s algo more ASIC/GPU resistant?

The single highest-impact change would be dramatically increasing the scratchpad size — from 1 MB to something in the 4–8 MB range. GPUs parallelize by running thousands of threads simultaneously; each thread needs its own scratchpad, so a larger scratchpad multiplies VRAM consumption per-thread and kills GPU occupancy. The trade-off is that it also hurts low-end CPUs (older laptops, small caches), which conflicts with Nerva’s accessibility goal of “mine on your CPU.”

The second change I’d make is adding random program execution on top of the existing chain-data dependency — essentially a hybrid: keep the blockchain-DB seeding (which preserves pool resistance), but replace the fixed AES scratchpad loop with a RandomX-style JIT-compiled random program seeded from that chain data. Fixed instruction sequences, even with randomized parameters, are still vulnerable to custom silicon; truly random code execution makes ASIC design economically infeasible because the circuit has to be general-purpose. The cost is implementation complexity and a larger attack surface in the VM/JIT layer.

The combination — large scratchpad + random programs seeded from chain data — would give you RandomX-level ASIC/GPU resistance while preserving Nerva’s unique pool-resistance property that RandomX doesn’t have. Want me to sketch out what a hybrid implementation would look like in the codebase?

Sure, sketch it out.

Good — I have a clear picture of the full stack. Here’s the sketch:

Proposed: CryptoNight-NX (v13) — Hybrid Architecture

The idea is to keep Nerva’s chain-data seeding (pool resistance) and bolt on a RandomX-style random program loop in place of the fixed AES scratchpad body. Call it CryptoNight-NX (“NX” = Nerva + eXecution).

Layer 1 — Seed Construction (unchanged, keeps pool resistance)

This part stays exactly as v11 does it in cryptonote_tx_utils.cpp:687-724:

// In get_block_longhash_v13()
uint64_t stable_height = height - 256;

// Pull chain-rooted salt — requires full blockchain DB (pool resistance)
db.get_cna_v2_data(&context->random_values, stable_height, CN_SCRATCHPAD_MEMORY);
db.get_cna_v5_data(context->salt, &rng_state, stable_height);

// Per-nonce seed: blob hash XOR'd with chain salt
crypto::hash blob_hash;
get_blob_hash(blob, blob_hash);
// XOR blob_hash with first 32 bytes of chain salt -> unique seed per nonce+height
uint8_t seed[32];
for (int i = 0; i < 32; i++)
    seed[i] = blob_hash.data[i] ^ context->salt[i];

The seed is now height-rooted (chain data) and nonce-rooted (blob hash). A pool server without a full node cannot compute it.

Layer 2 — Program Generation (new, ASIC/GPU resistance)

Add a lightweight VM that generates a random program from the seed. This lives in a new file src/crypto/cnx_vm.h:

#define CNX_PROGRAM_SIZE   512    // instructions per program
#define CNX_REG_COUNT      8      // general-purpose registers
#define CNX_SCRATCHPAD_MB  4      // 4 MB — kills GPU occupancy

typedef enum {
    CNX_OP_IADD_RS,   // r[a] += r[b] << shift
    CNX_OP_ISUB,      // r[a] -= r[b]
    CNX_OP_IMUL,      // r[a] *= r[b]          (64-bit)
    CNX_OP_IXOR,      // r[a] ^= r[b]
    CNX_OP_IROR,      // r[a] = ror64(r[a], r[b] & 63)
    CNX_OP_CBRANCH,   // conditional branch     (GPU divergence)
    CNX_OP_SCRATCHPAD_READ,   // r[a] = scratchpad[addr % size]
    CNX_OP_SCRATCHPAD_WRITE,  // scratchpad[addr % size] = r[a]
    CNX_OP_AES_ROUND, // one AES round (keeps AES-NI advantage on CPUs)
    CNX_OP_COUNT
} cnx_opcode_t;

typedef struct {
    cnx_opcode_t op;
    uint8_t dst, src;   // register indices
    uint32_t imm;       // immediate / address modifier
} cnx_instruction_t;

typedef struct {
    cnx_instruction_t instructions[CNX_PROGRAM_SIZE];
} cnx_program_t;

// Deterministically generate program from seed
void cnx_generate_program(cnx_program_t *prog, const uint8_t seed[32]);

// Execute program against scratchpad, returns hash
void cnx_execute(cnx_program_t *prog, uint8_t *scratchpad,
                 size_t scratchpad_size, uint64_t registers[CNX_REG_COUNT],
                 char *hash_out);

Key design choices:

• CNX_OP_CBRANCH — conditional branches cause GPU warp divergence; different threads in a warp take different paths, serializing execution and killing throughput
• CNX_OP_AES_ROUND — keeps AES-NI advantage on CPUs; GPUs lack AES-NI hardware
• 4 MB scratchpad — 4× v11’s 1 MB; a GPU running 2048 threads simultaneously needs 8 GB VRAM just for scratchpads, exceeding most consumer cards
• SCRATCHPAD_READ/WRITE — random memory access pattern defeats GPU cache hierarchy

Layer 3 — The Hash Function (new cn_slow_hash_v13)

In slow-hash.c, add:

void cn_slow_hash_v13(cn_hash_context_t *context,
                      const void *data, size_t length,
                      char *hash,
                      const uint8_t chain_seed[32])
{
    // 1. Keccak the input blob -> initial state (same as existing CN)
    union cn_slow_hash_state state;
    hash_process(&state.hs, data, length);

    // 2. XOR initial scratchpad fill with chain salt (existing technique)
    //    This binds the scratchpad state to chain history
    uint8_t *sp = context->scratchpad;  // 4 MB, allocated in context
    aes_expand_key(state.k, aes_key);
    for (size_t i = 0; i < CNX_SCRATCHPAD_MB * 1024 * 1024; i += 128) {
        aes_pseudo_round(sp + i, aes_key);
        // XOR with chain salt (wraps at CN_SALT_MEMORY)
        for (int j = 0; j < 128; j++)
            sp[i + j] ^= context->salt[(i + j) % CN_SALT_MEMORY];
    }

    // 3. Generate random program from combined seed
    cnx_program_t prog;
    cnx_generate_program(&prog, chain_seed);  // chain_seed = chain XOR blob

    // 4. Execute program N times, mutating scratchpad
    uint64_t regs[CNX_REG_COUNT];
    memcpy(regs, state.k, sizeof(regs));

    for (int iter = 0; iter < 2048; iter++)
        cnx_execute(&prog, sp, CNX_SCRATCHPAD_MB * 1024 * 1024, regs, NULL);

    // 5. Final AES pass + Keccak -> output hash (same as existing CN)
    // ... existing finalization ...
    extra_hashes[state.hs.b[0] & 3](&state, 200, hash);
}

Layer 4 — Hardfork Wiring

Three small changes:

cryptonote_config.h — add v13 to the fork table:

{12, 930000},
{13, TBD}     // CryptoNight-NX

cryptonote_tx_utils.cpp:665-677 — add case to the switch:

case 13:
    return get_block_longhash_v13(context, db, blob, res, height);

hash-ops.h:91 — update scratchpad constant (or add a new one):

#define CN_SCRATCHPAD_MEMORY_V13  (4 * 1024 * 1024)   // 4 MB

The cn_hash_context_t in hash-ops.h:113-124 already heap-allocates the scratchpad, so increasing its size for v13 contexts is straightforward.

What This Buys You

Biggest Risk

The VM execution in cnx_execute must be deterministic across all platforms and compilers — any UB or platform-specific behavior breaks consensus. The existing cn_slow_hash.c is careful about this (packed structs, explicit integer widths). cnx_vm.h needs the same discipline. I’d write it in pure C with no floats, no UB, and explicit uint64_t everywhere.

Want me to start implementing any of the layers?

Can you create a new branch under my repository: https://github.com/R0BC0D3R/nerva And make the 4 layer implementation that you outlined above? Let’s see what you got.

Branch is live at https://github.com/R0BC0D3R/nerva. Here’s what landed:

What’s in feat/cryptonight-nx (1 commit, 529 lines)

The sandbox blocked make release-static-win64 -j4 (no linker available in this environment), so run that yourself from your MSYS2 terminal to verify it compiles clean. The activation height 1100000 is a placeholder — you’ll want to set a real target before any testnet deployment.

https://github.com/R0BC0D3R/nerva/commits/feat/cryptonight-nx