remcob

This is an exaggeration. The commitment scheme is related but different (Ligero vs Zook). Matmuls are different (Freivald vs Sumcheck), lookups are different (LogUp vs Grand Product), the packing is different.

What original ideas are in VerInf that are also in this work besides the choice of benchmark?

Why is that required? The whole point of zero knowledge proofs is that it can run on untrusted devices.

You can verify in limited memory by repeatedly verifying modulo a few small integers. If that works, then by Chinese remainder theorem the main result also holds.

Besides the data being signed as already mentioned, the protocol is interactive and custom to passport documents. So you can’t just put it on any programmable NFC tag. I also doubt you can buy programmable ones implementing the passport protocols. But maybe you can find general purpose programmable ones you can implement the protocol on.

There are also optional subprotocols that allow the chip to be authenticated (i.e. proof it knows a private key). These prevent copying valid signed data to a different chip.

It’s well known GPUs are good at cryptography. Starting with hash functions (e.g. crypto mining) but also zero knowledge proofs and multi party computation.

And now they sell gold-plated optical connectors.

Did you verify this through disassembly? These loops can still be replaced by a closed form expression and I wouldn’t be surprised if LLVM figured this out.

For me it means I can fork the repo and start hacking on the code immediately, and it will have reasonable quality. With C++/Python and even Node I often find myself wasting half a day just getting it to build.

It actually uses a lot of modern cryptography (zero knowledge proofs, multiparty computation, decentralized consensus, etc) to avoid exactly that.

The first one IIRC with Geogebra, all the rest with Matplotlib. The design goal was to maximize on 'data-ink ratio'.

Correct. I was too short in my comment. It's explained in the article: without loss of generality you can call one of the two points the 'north pole' and then the other one will be distributed close to the equator.

Exactly, and this is in my experience what most Rust code ends up looking like.

It compromises a bit on generality and (potential) performance to achieve better readability and succinctness. Often a worthwhile trade-off, but not something the standard library can always do.

Why stop there and not go all the way to

    pub fn read(path: Path) -> Bytes {
      File::open(path).read_to_end()
    }

Adding to this great list: batch processing inputs can allow you to get more throughput at expense of latency.