Yesmem: a memory-hard PoW variant and a UTXO temperature-tiering scheme — feedback welcome
I’ve been working on an experimental BCHN-derived research fork (codebase: Bitcoin Cash Node v29.0.0) exploring two changes I’d like technical feedback on. This isn’t a launch announcement — I’m interested in whether the underlying design reasoning holds up under scrutiny from people who know the BCHN internals well.
1. Yesmem: memory-hard PoW with a serial mix chain
Problem: Most memory-hard PoW algorithms (Yespower, Argon2, etc.) are memory-bound but still leave room for ASIC/FPGA advantage once the memory-access pattern becomes predictable enough to pipeline or prefetch around.
Approach: Yesmem extends Yespower 1.0 by inserting a 100-round serial bit-manipulation chain after each random memory access in smix2 . Each round’s output determines the address of the next memory access, so:
- The mix chain cannot begin before the previous memory read completes, and the next memory address is unknown until the chain finishes — this removes the prefetch window entirely.
- The chain is strictly serial (
x(n+1) = f(x(n), v0(n), v1(n))), so SIMD/multi-core/FPGA pipelining collapses to single-core serial throughput within one hash. - Every 10 rounds the chain reloads two words from a data-dependent address across the full working set, re-coupling the “compute” and “memory” phases repeatedly rather than once per outer iteration.
Core parameters:
N (cost factor) 2^21
r (block size) 32
Memory per thread 128 × N × r = 8 GiB exactly
ISA baseline x86-64-v3 (SSE4.2/AVX2/BMI2/FMA) / ARMv9.0-A (SVE2/BITPERM)
The consensus build explicitly excludes AVX-512/AVX-10/XOP at compile time to guarantee bit-identical hashes across validators. PEXT/PDEP (or SVE2 BITPERM on ARM) are used for the bit-scattering step in each round.
Open question I’d like scrutiny on: whether the 10-round reload interval is the right tradeoff between closing the pipelining window and keeping per-hash latency low enough for 8 GiB/thread to remain practical on consumer RAM at a 600s block time. I chose it empirically rather than from a formal proof and would value pushback.
2. UTXO temperature tiering (Normal → Cold → Ice)
Problem: Full in-memory chainstate doesn’t scale indefinitely; most long-lived UTXOs are never touched again but still cost RAM/disk to keep fully indexed.
Approach: a deterministic, consensus-level demotion schedule moves outputs through three tiers based on value and confirmation height:
temperature(h) = value − COOLING_RATE × (h − heightAnchor)
demotionBlock = heightAnchor + floor(value / COOLING_RATE) + 1
- Normal : full in-memory chainstate.
- Cold : compressed, address-level index on disk — spending needs no block read.
-
Ice : block-height pointer only — spending triggers a block read to reconstruct output data on demand (handled via a point-to-point
UTXO_REQUEST/UTXO_RESPONSEexchange with the node that last relayed the spend, not a network broadcast).
The demotion formula and Normal→Cold schedule are consensus rules (every node computes them identically); the Cold protection period and Ice index depth are node-operator configuration, not consensus.
Open question: whether the point-to-point Ice-reconstruction request ( utxofall ) introduces a DoS surface if a node systematically requests data for outputs it could otherwise derive locally, and whether that needs a rate limit at the consensus layer rather than just at the P2P layer.
Happy to share the full spec (block header layout, ASERT anchoring, the TX1/TX2 CLTV-based instant-payment scheme) if there’s interest in a specific part. Mainly looking for holes in the reasoning above from people who’ve actually worked with BCHN’s mempool/chainstate code.
