amethyst/quartz/plans/2026-08-13-gpu-pow-mining.md

Can the phone's GPU mine NIP-13 proof of work?

Date: 2026-08-13 Status: analysis + measurements; recommendation is NOT to build a GPU miner Verdict: a flagship phone GPU lands at roughly the same SHA-256 throughput as the CPU cores the miner already uses, because ARMv8 CPUs have SHA-256 in silicon and mobile GPUs do not. The unclaimed speedup is on the CPU side: a midstate is ~3x on JVM targets, and on Android it hinges on Conscrypt's per-digest JNI cost, which is still unmeasured.

Also specifies advancing created_at while mining, which shares the same pass structure a midstate would need.

The question

Can we offload PoWMiner's hash loop to the phone GPU to mine NIP-13 proof of work faster?

What the miner does today

quartz/…/nip13Pow/miner/PoWMiner.kt serializes the event once into the NIP-01 id payload, finds the nonce inside that byte array, then mutates the nonce bytes in place and re-hashes:

fun reachedDesiredPoW(byteArray: ByteArray) =
    PoWRankEvaluator.atLeastPowRank(sha256Into(hashOut, byteArray, byteArray.size), …)

PoWMiner.mine() races workers copies of that search over disjoint nonce prefixes. PoWPolicy.minerWorkers() sets workers = cores / 2 so the UI and relay client keep their cores. sha256Into is MessageDigest("SHA-256") from a ThreadLocal (quartz/…/utils/sha256/Sha256.jvmAndroid.kt), i.e. Conscrypt → BoringSSL.

Two facts about that loop drive everything below.

1. It re-hashes the whole payload every attempt

fastMakeJsonForId serializes [0,pubkey,created_at,kind,tags,content]. The PoW tag is appended as the last tag, so only the tail — the rest of the nonce tag plus the whole content string — changes between attempts. Everything before the 64-byte SHA-256 block containing the nonce is constant and could be absorbed once into a midstate.

Measured layout (4 tags: 2 e + 2 p, nonce at byte 407):

Payload	Size	Padded blocks	Blocks that actually change
49-char note	473 B	8	2
223-char note	663 B	11	5

Six of the eight (resp. eleven) block compressions per attempt are recomputing bytes that never change. Real posts carry more p tags than this sample, which pushes the nonce further right and makes the constant prefix bigger, not smaller.

2. Cost model of the current hash call

Single-thread sha256Into on the build container's x86-64 JVM, payload swept from 32 B to 4 KB:

Payload	Blocks	hashes/s	µs/hash
32 B	1	4,025,423	0.248
64 B	2	2,197,941	0.455
256 B	5	1,010,665	0.989
1024 B	17	329,215	3.038
4096 B	65	88,845	11.256

Those numbers were wrong — about 3.3x pessimistic — and are kept here only because the first two revisions of this plan reasoned from them. See the correction below; everything downstream uses the corrected model.

3. Correction: the JVM already runs SHA-256 at hardware speed

The table above suggested cost ≈ 76 ns + 172 ns/block, which made the JVM look 3.7x slower than openssl speed -evp sha256 (1,357 MB/s ⇒ 47 ns/block) on the same CPU. That gap does not exist. Re-measured with a best-of-5 loop:

bytes	blocks	ns/hash	marginal ns/block
64	2	134	—
256	5	270	45
512	9	455	46
1,024	17	846	48
4,096	65	3,143	47
65,536	1,025	47,395	46

Corrected model: cost ≈ 42 ns fixed + 46 ns per 64-byte block — the marginal cost is flat at every size and equals OpenSSL's 47 ns/block. The HotSpot intrinsic is doing the work: -XX:-UseSHA256Intrinsics gives 390 ns/block (8x worse) and -XX:TieredStopAtLevel=1 gives 583 ns/block.

The original figure was a single unguarded 500 ms sample with no best-of-N, taken in the same Gradle invocation as the module's first full compile (4-core container, 6 GB Gradle daemon + 8 GB Kotlin daemon). Every controlled repetition since lands at 46–48 ns/block: standalone java and inside a Gradle test worker; the original timing method and a best-of-5; with and without four CPU hogs; and immediately after a forced recompile. Compilation shape was ruled out too — an OSR-compiled loop in main and a hot C2-compiled method differ by 1.02x.

There is therefore no "slow regime". OpenJDK reaches hardware SHA-256 with an intrinsic over pure-Java code — no JNI at all — and ARMv8 crypto extensions land in the same place (~2 GB/s per core ≈ 32 ns/block). Android is the one platform whose per-call cost is unmeasured, because Conscrypt makes a real JNI call per digest where OpenJDK makes none.

Lesson for the next measurement: take best-of-N, never a single wall-clock window, and never in the same Gradle invocation that compiled the code.

What GPU APIs are actually reachable

API	Reachable from Kotlin?	Notes
OpenGL ES 3.1 compute	Yes — android.opengl.GLES31, no NDK	Only realistic pure-Kotlin path. ES 3.1 guarantees just 4 SSBO bindings; needs an offscreen EGL pbuffer context on its own thread
Vulkan compute	No — NDK only	Better (subgroups, less driver overhead), but amethyst has no C/C++ toolchain today; would add CMake + NDK to the Android build
OpenCL	No	Not part of Android's guaranteed surface; dlopen("libOpenCL.so") works on some Qualcomm/ARM devices and not others
RenderScript	No	Deprecated in API 31; Google's own migration guide points at ES 3.1 compute

So: OpenGL ES 3.1 compute shaders, with a mandatory CPU fallback for devices below ES 3.1 (minSdk here is 26, so that fallback is not optional).

Why the GPU does not win

Mobile GPUs have no SHA-256 hardware. ARM CPUs do. ARMv8 Cryptographic Extensions add SHA256H/SHA256H2/SHA256SU0/SHA256SU1, and BoringSSL dispatches to them at runtime. A GPU has to emulate the same work out of general integer ALU ops.

Ops per 64-byte block in GLSL ES (no rotate builtin, so every rotr is shl+shr+or):

• message schedule, 48 × (2 × σ ≈ 9 ops + 3 adds) ≈ 1,000 ops
• 64 rounds × (Σ1 11 + Ch 4 + Σ0 11 + Maj 5 + 7 adds) ≈ 2,400 ops

≈ 3,400 integer ops per block compression.

	Throughput per block-compression
Flagship GPU (Adreno 750 class, ~1.5 T int ops/s at ~40% ALU efficiency)	≈ 175 M/s
Flagship CPU, ARMv8 SHA-2 ext (~2 GB/s per big core = 31 M blocks/s), 4 workers	≈ 125 M/s
Mid-range GPU	≈ 20–50 M/s

The GPU estimate agrees with the ~80–150 MH/s figure quoted for SHA-256 on mobile in hashcat-style benchmarks, so two independent derivations land in the same place.

That is ~1.4x on a flagship, and a loss on mid-range hardware — for a GPU-vs-CPU offload that would normally be worth 10–50x. Both paths benefit equally from the midstate optimization, so the ratio does not improve.

And the 1.4x costs more than it's worth

• The GPU is the compositor. Saturating it janks the whole system, including other apps. The CPU miner already gives up half the cores (minerWorkers) specifically to avoid this; there is no equivalent "half a GPU".
• Power and thermals. Sustained GPU load is ~3–5 W and throttles within ~60 s. PowMiningForegroundService runs under the Android 14 shortService type with a hard ~3 minute budget — most of which would be spent throttled.
• Dispatch latency. Kernel launch + readback is ~1–5 ms, so batches must be large (~10⁶ nonces) to amortize. At the difficulties users actually pick, the whole job can finish inside one batch, wasting most of it.
• Play policy adjacency. Google prohibits apps that mine cryptocurrency on-device (remote management is allowed). NIP-13 PoW is not cryptocurrency, but a GPU-saturating component named "miner" invites review friction that the CPU path has never attracted.
• Cost. ~1,000 lines of GLSL + EGL context management + batch/nonce plumbing + result verification, Android-only, shared with neither desktopApp nor cli, and it has to be kept in lockstep with the CPU nonce enumeration forever.

What to do instead

1. Midstate — ~3x on JVM targets, unknown on Android. SHA-256 is state ← compress(state, block) over 64-byte blocks, strictly sequential. Every block before the one containing the nonce is identical on every attempt, so it can be absorbed once into 8 uint32 words and restored per attempt. The boundary is (searchFrom / 64) * 64 — searchFrom, not nonceStarts, because a parallel worker's fixed prefix is constant too. This is legal only because the payload length is constant within one search() pass (the nonce only grows on exhaustion, which restarts the pass), so the padding and length suffix don't move.

On the corrected model (42 + 46n), for a JVM target:

	now	with midstate	speedup
Short note, 8 blocks → 2	410 ns	134 ns	3.1x
Long note, 11 blocks → 5	548 ns	272 ns	2.0x

The fixed cost is only 42 ns there, so cutting block count is nearly a pure win. That is the case for doing it in desktopApp/cli/geode.

Android is the open question, and it turns on one unmeasured number: Conscrypt's per-digest JNI cost. OpenJDK pays none (intrinsic over pure Java); Conscrypt pays a real call. If that overhead is ~200 ns against ~32 ns/block on ARMv8, an 8-block attempt is 456 ns and a 2-block one is 264 ns — and neither route to a midstate keeps that win. MessageDigest doesn't expose state, so it is either clone()-ing a pre-absorbed digest (keeps the ARM instruction but adds a second JNI call) or a Kotlin compression function in commonMain (drops to zero JNI but forfeits the hardware instruction, at maybe 300–500 ns/block on ART). Whether Conscrypt's digest is even Cloneable is also unverified.

So: measure Conscrypt's fixed per-digest cost on a real device first. That single number decides whether Android gets the JVM's 3x, roughly nothing, or a regression.

2. Kill the per-call floor, if there is one. If Android does turn out to be JNI-bound, the way past it is to run many attempts below the JNI boundary — one native call that restores the midstate, walks N nonces and returns a winner. That keeps the ARMv8 instruction and pays the call cost once per million attempts. It needs an NDK toolchain, which amethyst does not have today (nestsClient builds native code, so it is not unprecedented). It is the same batching structure the GPU path needs — and it beats the GPU by keeping the hardware SHA-256. Conditional on the measurement above; do not build it on the estimate.

3. PoWMiner only uses half the cores. minerWorkers = cores / 2 is right while the user is composing, but a job that has been handed to the foreground service and is no longer blocking any UI could use more.

4. Delegate off-device. quartz/…/nip90Dvms/eventPowDelegation/ already models NIP-90 kinds 5970/6970 — hand the template to a DVM with real hardware. That beats every on-device option and is already specced.

Advancing created_at while mining — SHIPPED

Not a speedup — a correctness fix that this analysis is a prerequisite for, because it interacts with the midstate. Implemented as described below; PoWMiner.run/mine take an optional refreshCreatedAt: (() -> Long)?, covered by quartz/…/PoWMinerCreatedAtTest.kt.

NIP-13: "It is recommended to update the created_at as well during this process." We do half of it. PoWPublishQueue.enqueue(refreshCreatedAtOnStart = …) and the anonymous path in ShortNotePostViewModel both stamp a fresh TimeUtils.now() at mining start, because "a job that waited in the queue (or was restored after a process death) would otherwise publish visibly in the past". But the mining run itself is the same problem: 28 bits at a few M h/s is ~a minute, 30 bits several — and PoWPolicy.MAX_DIFFICULTY is 40. A post can still land in the feed minutes stale.

Where it goes. search() already re-serializes per pass in its do { … } while (nextSize < 50) loop; today a pass only ends on nonce-space exhaustion. Bound a pass by either exhaustion or a wall-clock budget (~1 s), and re-stamp createdAt at the top of each pass. PoW search is memoryless, so restarting a pass throws away no progress.

API shape. Don't make EventTemplate.createdAt lazy — it is @Immutable, @Serializable, and persisted by PoWJobPersistence; a field that changes on read breaks value semantics and the checkpoint format. Pass the miner a clock instead: PoWMiner.mine(…, refreshCreatedAt: (() -> Long)? = null), null meaning today's frozen behaviour. The consumers are already correct — PoWNostrSigner forwards mined.createdAt to signer.sign(…), and the queue publishes the mined template — so this is contained inside PoWMiner plus one flag at the call sites.

The new parameter goes last, after isActive, so the trailing-lambda call sites keep binding their lambda to isActive. Kotlin would otherwise silently retarget them at refreshCreatedAt; the Boolean/Long mismatch makes that a compile error rather than a bug, but those sites were rewritten to a named isActive = { … } anyway.

"When we can" is already modelled. Reuse refreshCreatedAtOnStart's predicate rather than inventing a second one; its comment already states the exclusion — "Must stay false for scheduled posts, whose future created_at is intentional." Replaceable/addressable kinds (created_at is their conflict-resolution key) and NIP-59 seals/gift wraps (deliberately randomized timestamps) are already excluded upstream by PoWPolicy.neverMine and kindsToMine. Clamp with maxOf(previous, now()) so a wall-clock step backwards cannot move a post into the past.

Interaction with the midstate. created_at sits before the tags in [0,pubkey,created_at,kind,tags,content], so every bump invalidates the whole midstate. That costs one prefix re-absorb (~1 µs) per bump against millions of attempts between bumps — irrelevant, and it happens at the pass boundary where the payload is being rebuilt anyway. The digit count of created_at is stable (10 digits until 2286), but re-serializing per pass sidesteps that question entirely.

Bonus. A fresh created_at is a fresh search space, which makes the nextSize += STARTING_NONCE_SIZE growth loop and its RuntimeException("Could not find PoW") escape hatch effectively dead: one pass over a 5-char nonce is 73⁵ ≈ 2.1e9 candidates, and each bump grants another 2.1e9.

If we want the GPU experiment anyway

Do it as a measurement, not a feature:

1. expect fun gpuHashRate(): Double? in quartz, Android actual on GLES31, returning null when compute shaders are unavailable.
2. A minimal SHA-256 compute shader over a fixed 2-block tail with midstate uploaded as 8 uints, one nonce per invocation, atomically reporting a winner.
3. Add it to benchmark/…/PoWBenchmark.kt next to generatePow and run both on real devices (a flagship and a mid-ranger).

Ship it only if the on-device number beats the CPU by enough to pay for the jank — the analysis above says it will not, but that measurement is the only thing that settles it, and it cannot be taken in this container (no GPU, no device).

Reproducing the measurements

The layout table came from a throwaway quartz JVM test that serialized templates via EventHasherSerializer.fastMakeJsonForId and located the nonce with ByteArray.indexOf. The corrected cost sweep timed sha256Into per size with a 300k-iteration warmup and best-of-5 timing, cross-checked against standalone Java (java Sweep.java) and openssl speed -evp sha256. Neither probe was kept — they printed rather than asserted.

A permanent version belongs in benchmark/, where it can be taken on-device. The one number worth having there is Conscrypt's fixed per-digest cost: subtract the fitted slope from a 1-block hash, exactly as the 42 + 46n fit above does. Everything the Android side of this plan is still undecided about follows from it.