Mine a SHA3-256 Digest

Search for a message with your own name whose SHA3-256 digest starts with eight zeros. The search runs in WebAssembly or on the GPU, and it is saved while it runs.

Proof of workdemo

Objectives

Explain why a fixed target costs 2^n hash calls and gets no birthday discount.
Measure your machine's hash rate and turn 2^32 into a wall-clock time.
Explain why the expected remaining time does not fall as a search continues, and read the 63% figure at the expected count.
Scale the measurement to 2^128 and say what the collision resistance of SHA3-256 means in those terms.
Verify a claimed result independently, and explain why checking is cheap while finding is not.

25%

Search for a message whose digest starts with four zero bytes, in WebAssembly, and watch 2^32 turn into minutes.

Here is the puzzle. Take your name, wrap it in two random fields and the course label, add a counter, and hash the whole string with SHA3-256. Keep changing the counter until the digest starts with eight zeros — eight hexadecimal digits, which is four zero bytes. Nothing else about the digest matters.

SHA3-256( salt || "CPE645/CS685" || First || Last || tag || nonce ) = 00000000…

Your message

first name

last name

salt, random

tag, random

The two random fields are generated for you when the page loads. They matter: without them every student in the room would be searching the same space and finding the same answer, and the first one to finish could hand it to everyone else.

the message at nonce 0

CPE645/CS685AdaLovelace0000000000000000

its digest

a6c809e33dca481503aad17a05b0c01e0bc59ca4bc1ced49ce67a62254e2e568

That digest starts with 0 zeros as printed, 0 zero bits. The nonce is the last sixteen characters, written as hexadecimal, and it is the only part the search changes. Everything else is fixed, so every candidate is the same length and the count of hashes is the whole cost.

What it costs

Each try is an independent chance of 2⁻ⁿ for n zero bits, and the target is fixed before the search begins. So there is no birthday shortcut here: this is the preimage side of the cost comparison, where the work is 2ⁿ rather than 2^n/2.

leading zeros required in the digest

Eight is the one the assignment asks for: eight hexadecimal zeros is four zero bytes, or 32 bits. Slide left for something that finishes while you watch, right for something that does not. The slider is locked while a search is running.

what this setting costs

zeros required   8 hex digits = 32 bits = 4 bytes
expected hashes  2^32 = 4.29B
at this machine  run a search to measure the rate

Expected hashes and expected time for a range of difficulties, at the rate measured on this machine.
Zeros	Bits	Expected hashes	At the rate measured here
2	8	2^8 = 256	start a run to measure
4	16	2^16 = 65.5k	start a run to measure
6	24	2^24 = 16.78M	start a run to measure
8	32	2^32 = 4.29B	start a run to measure
10	40	2^40 = 1099.51B	start a run to measure
12	48	2^48 = 281474.98B	start a run to measure

Eight zeros is 32 bits: about 4.3 billion hashes expected, a few minutes of a laptop and well under a minute of a fast GPU. Now scale the same table past its end. SHA3-256 is designed for 128-bit collision resistance, which is 2¹²⁸, or thirty-two zeros. Multiply the time in the last row by 2⁹⁶ and the answer stops being a number anyone has a use for.

The search runs in WebAssembly, in as many workers as you ask for. Readable JavaScript is not fast enough for this: Keccak works on 64-bit lanes, JavaScript numbers do not, and the readable version in src/lib/keccak.ts pays for every rotation. The compiled module runs the same twenty-four rounds roughly a hundred times faster.

The engine

Loading the WebAssembly engine…

Whichever engine you pick, it is checked before it is used: it hashes five messages, including the lengths either side of the 136-byte rate where a padding mistake would hide, and the digests have to match the readable implementation in src/lib/keccak.ts. An engine that disagrees is refused rather than trusted.

workers

One worker per core is the usual ceiling, and one fewer than that leaves the browser something to draw with. Twice the workers is twice the hash rate only while there are cores left to fill.

progress

hashes          0
rate            not measured yet
searched to     nonce 0
elapsed         0 s
expected total  4.29B hashes for 32 zero bits
chance so far   0.0% of runs this long have finished
expected still  measure the rate first

Read the last two lines together. The expected remaining time does not fall as the search goes on, because each try is independent of every try before it: the search has no memory and no progress in the ordinary sense. The bar shows the chance a run this long has already finished, which is 63% at the expected number of hashes, not 100%.

What each engine measured

the rate each engine reached on this machine

WebAssembly   not measured yet
WebGPU        not available here
2^32 would take
  WebAssembly -
  WebGPU      -
run both engines to compare them

Run a search on one engine, stop it, switch and run the other. The ratio is this machine's answer, not a general one. An RTX 3090 reached 89 times the rate of eight WebAssembly workers on a Ryzen 7900X, finishing eight zeros in eighteen seconds where the CPU path needed twenty-six minutes; an integrated GPU gives a small multiple, and a machine without WebGPU gives none. That spread is the point. A cost in hash calls is fixed by the puzzle; a cost in time belongs to whoever is paying for it, and an attacker chooses the hardware.

This is what a cost estimate in the deck actually means. 2³² is not "a while"; it is the number in the second column, and your machine is paying it at the rate in the third. Everything else in the course that says 2⁶⁴ or 2¹²⁸ is the same measurement with a different exponent.

A search at 32 bits outlives a coffee break, a closed lid and a reload, so the page saves it. Two places: this browser, and a block of text you can carry anywhere.

Saved in this browser

Nothing is saved yet. Start a run and this box fills in within a few seconds.

The record is written to localStorage every couple of seconds and again when the run stops. It holds the name you typed, the two random fields, the difficulty and the counters. It stays in this browser: this site has no backend and nothing here is sent anywhere.

Not a cookie, deliberately. A cookie is capped near 4 KB, and every cookie is attached to every request to the host, so a cookie would put your name and your search state into the web server's logs on every page load in exchange for nothing.

Carried to another machine

this run as text: copy it out, or paste one in

saved run, JSON

Copy this before you close the lid. Paste it on another machine and press Load.

Pasted text is checked field by field before any of it is used: a record from another version, a nonce that is not a number, or anything that is not valid JSON is refused whole rather than applied in part. It is data from outside the page, and the page treats it that way.

The searched to nonce is exact. It is the lowest nonce any worker was still busy with when the run stopped, not the highest one handed out, so resuming from it searches every nonce exactly once. A saved run is a real claim about which part of the space is finished.

Nothing found yet

Start a run in the step above. At 32 bits this takes minutes, not seconds; try 16 or 20 bits first to see the whole cycle finish while you watch.

Check any nonce by hand

nonce, decimal

message

CPE645/CS685AdaLovelace0000000000000000

digest

a6c809e33dca481503aad17a05b0c01e0bc59ca4bc1ced49ce67a62254e2e568

0 leading zero bits, 32 needed

Anyone can verify a claimed answer in one hash. Finding it took billions. That gap, cheap to check and expensive to produce, is the whole mechanism behind proof of work, and it is built from nothing but a hash function nobody can invert.

One honest caveat about the analogy. Bitcoin mining is this, on a block header, with the difficulty adjusted so the network finds an answer every ten minutes. What it buys there is not the digest but the cost: rewriting history means paying it again. Here nothing is bought, and the target is fixed rather than adjusted, so what this page measures is exactly one thing — the price of 2³² hash calls on your own machine.

The readable implementation behind the verification is a teaching implementation: written to be read, not constant time, not for production use. The WebAssembly core is the same algorithm compiled for speed, and it is checked against the readable one before use.

step 1/4

CPE 645 / CS 685

Mine a SHA3-256 Digest

SHA3-256, Step by Step

Diffie–Hellman Key Exchange