Apply Direct Pressure · dpbk.ink/adp

The scribble decides where to look.

Four points sampled from your drawing each seed an independent hunt for a Sophie Germain prime — a prime p where 2p+1 is also prime. Finding one takes a search. Checking one takes two Miller–Rabin tests. That gap is the whole gate.

Draft This page is not wired to the live gate. The prime hunting is real — the same worker that ships in challenge.html, finding genuine 512-bit primes in your browser. The server's half (seed derivation, verification) is simulated in-page so this can run from a link. Nothing here can unlock the actual EPUB.

Try it

Scribble until the bar turns green, then lift your finger

Scribble in the box to begin

Your drawing picks the starting points. Keep scribbling as long as you like — every stroke moves them.

Prime size Hunts Window

What you are actually running

Real here, simulated there

Real — same code as production

The segmented sieve over primes below 2¹⁶, rejecting candidates on both p and 2p+1 — the half that makes it a Sophie Germain search
12-base Miller–Rabin on BigInt
Pressure capture, liveness thresholds, the green latch
Redrawing mid-search abandons the hunt
Window exhaustion reported rather than spun on

Simulated — the server's half

Seed derivation runs here with a throwaway in-page key; in production it is HMAC(server_secret, …) so the seed cannot be predicted or run backwards
Verification: the real gate re-checks every prime with three unpredictable extra bases, because the public 12 stop being decisive above 2⁶⁴
No token, no commit binding, no throttle, no EPUB

Choosing the size

Measured, 100 trials each, 4 hunts

Bits	Median	p95	Candidates	Phone p95 ≈	Exhausted
448	334 ms	724 ms	274,028	2.9 s	0/100
512	541 ms	1,111 ms	352,190	4.4 s	0/100
576	907 ms	1,681 ms	475,596	6.7 s	0/100

Measured on the 32-core workstation with node tools/tune-pow.mjs, which extracts the search code from the shipped page so it measures what visitors run. A phone is roughly 3–5× slower, and that is the device the budget has to survive — which is why 512 is the default rather than 576.

The honest caveat

This prices CPU, not elapsed time

The hunts share nothing, so the work is embarrassingly parallel. For you that caps out near 2× no matter how many cores you own — you need all the hunts, so you pay the slowest one rather than the sum, and for four hunts the expected ratio is 1 + ½ + ⅓ + ¼ ≈ 2.08. Measurement agreed: 1.97× on four threads. For a scraper, cores buy a full linear win, because they batch across downloads and care about throughput rather than latency. So the gate costs about half a CPU-second per download. If the goal were ever three seconds regardless of hardware, prime search cannot provide that at any size — that is what a VDF is for. This is the third layer, behind Anubis and the liveness check, not the only one.