remcob

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.

The distance between two uniform random points on an n-sphere clusters around the equator. The article shows a histogram of the distribution in fig. 11. While it looks Gaussian, it is more closely related to the Beta distribution. I derived it in my notes, as (surprisingly) I could not find it easily in literature:

https://xn--2-umb.com/21/n-sphere

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.

Why should we weigh by the number of different digits? I.e. is there an argument why the cost of a single digit is linearly proportional to the number of values it can hold?

To me this seems like the weak point in the argument.

The exchange rate for the WorldCoin was last updated on October 21, 2019.

This is a different token. And I wouldn't trust a site with such outdated rates.

It’s also the only high production game with native MacOS & M1 support I could find. I got the early access just to see what M1 GPU can do and was impressed.

This is essentially the Birthday paradox. You need a quadratically better false match rate to deduplicate than to authenticate. It’s also why Worldcoin went with Irises (highest entropy among biometrics), custom hardware, custom optics and an in-house trained algorithm.

WebKit was more or less ‘stolen’ from KDE’s KHTML and KJS. They forked it, developed it in secret, and did not publish anything until it diverged so far from source that it could not be merged back in. While technically legal, it definitely goes against the spirit of open source. LLVM is a better story: also not invented at Apple, but they hired the core developers to continue working on it.

I started reading the ‘crypto’ in cryptocurrency as in cryptozoology. It makes more sense that way.

carbon dioxide

You probably mean nitrous oxide (N₂O). Both are sold in small aluminum canisters for culinary use. CO₂ is acidic and is quite unpleasant to inhale. N₂O is listed in the article (Table 1) as one of the inhalant anesthetics.

I had the experience of going through both IV general anesthesia (presumably propofonol) and syncope in the last two weeks and for me propofonol was much faster getting in and out of: like falling asleep and I woke pleasantly remembering a dream. Syncope for me was much harsher: tunnel vision as a passed out and I came by initially not remembering where or who I was, like my brain did a cold boot.

I wrote this intro for a friend and since then more people have found it useful:

https://xn--2-umb.com/22/approximation

If you want a proper textbook, I recommend L.N. Trefethen (2019). “Approximation Theory and Approximation Practice.” Which is available online here:

https://epubs.siam.org/doi/book/10.1137/1.9781611975949

"Vegetative electron microscopy" is likely a poor rephrasing of "low-energy electron microscopy", which is a thing [0].

[0] https://en.wikipedia.org/wiki/Low-energy_electron_microscopy

It's worth noting that Cayman has virtually no Crypto because of the above.

Many reputable crypto projects I know are set up as Cayman Foundations. For the same reasons: great regulatory clarity and execution.

Yes they should. A deposit liability arises from the fact that they received an asset in a deposit transaction. Liabilities and assets aren't mutually exclusive in any transaction, and both must increase when you receive a customer's deposit, or else where does the liability come from?

Does a cash transporter count the contents of their armored vans as assets? Does DHL count the contents of their vehicles and warehouses as assets? Why should exchanges be different?

I know it's the law for exchanges to account custodial funds as assets (SAB121), but I don't see why it should be this way. In fact it seems to achieve the opposite of consumer protection.

This holds true for regular travel nearing light speed too: For an external observer the spaceship never goes faster than light, but the passengers clocks slow down and they can experience arbitrarily high faster-than-light speeds.

For some reason I never see this discussed when people talk about FTL travel, maybe I'm wrong?

I toy with microcontrollers. For hobbyists like me, ARM processors are still the most sensible choice. I'm not expecting any shift from that for at least five years.

I started using ESP32C3s in my projects. They are cheap powerful RISC-V micros supported by Arduino SDK. IMHO it's already better than the ARM offerings, but I'm still waiting for good Rust support.

so you reduce the effective keysize to 256-6*$num_chars

Correct: you reduce the search-space of the private key, but you simultaneously increase the cost of brute-forcing by the same amount because finding keys to try in the smaller search-space takes more work (the same work as generating vanity addresses).

As long as brute-forcing is the most efficient way to crack the attacker has to do the same expected amount of work on vanity addresses.

It's also missing the my favorite children's animated series "Alfred J. Kwak" [1]. A Dutch-Japanese collaboration notable for it's exceptionally mature treatment of very difficult topics such as apartheid, environmentalism, inequality, doping in sports, facism, etc.

[1] https://en.wikipedia.org/wiki/Alfred_J._Kwak

Edit: After seeing the series, Tove Jansen allowed the same Dutch-Japanese crew to animate the Moomins in a Dutch-Japanese-Finish collaboration. [2]

[2] https://en.wikipedia.org/wiki/Moomin_(1990_TV_series)

In my experience Rust has become the go-to language for applied cryptography and is becoming increasingly popular for embedded/iot development. We're currently hiring for both and experience a scarcity of developers.