Show a progress bar for the probability of completing the proof of work challenge (#87)

Since the challenge is done off of the main thread, there is no simple
way to report the progress done towards completing it. This change
adds a callback parameter, `progressCallback`, which is called with
the most recently attempted nonce every ~1024 iterations (should this
be configurable?). For the single-threaded "slow" algorithm, this is
exactly every 1024 iterations. For the multi-threaded "fast" algorithm,
threads take turns reporting in a round-robin as then notice they
have passed a multiple of 1024. This complexity is to avoid individual
threads falling behind their siblings due to the overhead of messaging
the main thread. To minimize this overhead as much as possible, a
regular number is sent instead of an object.

With the new information provided by the callback, a hash rate display
is added to the challenge page. This display is updated at most once
per second and set with tabular numbers to avoid the constantly changing
value being too visually distracting.

* web: show a progress bar based on completion probability

To provide more feedback to the user, the spinner is replaced with a
progress bar of the probability the challenge is complete. Since it
looks a little weird that a progress bar would fill up a quarter of the
way and then jump to the end (even though the probability would make
that happen 1 in 4 times), the bar is mapped with a quadratic easing
function to move faster at the beginning and then slow down as the
probability of redirection increases. If the probability exceeds 90%,
a message appears letting the user know things are taking longer than
expected and to continue being patient.

Signed-off-by: Xe Iaso <me@xeiaso.net>

1 files changed, 28 insertions, 4 deletions

diff --git a/web/js/proof-of-work.mjs b/web/js/proof-of-work.mjs
index b4f9c53..60d8d61 100644
--- a/web/js/proof-of-work.mjs
+++ b/web/js/proof-of-work.mjs
@@ -1,4 +1,9 @@
-export default function process(data, difficulty = 5, threads = (navigator.hardwareConcurrency || 1)) {
+export default function process(
+  data,
+  difficulty = 5,
+  progressCallback = null,
+  threads = (navigator.hardwareConcurrency || 1),
+) {
   console.debug("fast algo");
   return new Promise((resolve, reject) => {
     let webWorkerURL = URL.createObjectURL(new Blob([
@@ -11,9 +16,12 @@ export default function process(data, difficulty = 5, threads = (navigator.hardw
       let worker = new Worker(webWorkerURL);
 
       worker.onmessage = (event) => {
-        workers.forEach(worker => worker.terminate());
-        worker.terminate();
-        resolve(event.data);
+        if (typeof event.data === "number") {
+          progressCallback?.(event.data);
+        } else {
+          workers.forEach(worker => worker.terminate());
+          resolve(event.data);
+        }
       };
 
       worker.onerror = (event) => {
@@ -55,6 +63,8 @@ function processTask() {
       let nonce = event.data.nonce;
       let threads = event.data.threads;
 
+      const threadId = nonce;
+
       while (true) {
         const currentHash = await sha256(data + nonce);
         const thisHash = new Uint8Array(currentHash);
@@ -78,7 +88,21 @@ function processTask() {
           break;
         }
 
+        const oldNonce = nonce;
         nonce += threads;
+
+        // send a progess update every 1024 iterations. since each thread checks
+        // separate values, one simple way to do this is by bit masking the
+        // nonce for multiples of 1024. unfortunately, if the number of threads
+        // is not prime, only some of the threads will be sending the status
+        // update and they will get behind the others. this is slightly more
+        // complicated but ensures an even distribution between threads.
+        if (
+          nonce > oldNonce | 1023 && // we've wrapped past 1024
+          (nonce >> 10) % threads === threadId // and it's our turn
+        ) {
+          postMessage(nonce);
+        }
       }
 
       postMessage({