Show HN: Satoshi9000 analog BTC key generator (mechanical)

Not sure I’d call it analog. Mechanical it is, but all the computation control is digital. A mechanical one would probably have a camshaft for storing the program and use gears to make measurements and computations.

Would probably need a large engine to power it as well, with careful control because the resisting force would vary along the machine cycles (this could be used as a side channel attack vector to figure out internal state from resisting force).

It's certainly the case that the coin/dice shaking is purely mechanical because before I built the control box, I operated the machine by simply connecting the motor to a bench power supply and applying the necessary voltage (which I would vary) for an amount of time (which I could vary) in a chosen rotational direction (which I could change). I could read the 1's and 0's just by looking at the coins and dice through the transparent dome.

The control box was a convenience and made the process fully programmable by the user. Which makes the machine far more flexible and useful.

I call it analog randomness because that's what I expect from the real world. For thousands of years, humans have used coins and dice to generate uncertain outcomes. And the fact that they typically generate only one of N outcomes (N=2 for coins, N=6 for common dice) is why humans use them. It is also why the Satoshi9000 uses them, and because its a kind of randomness that humans have an intuitive recognition of.

It's quite a respectable accomplishment, don't get me wrong.

Now I'm thinking of a random number generator that uses a mechanical calculator printer (but I don't think there are any hex-capable ones easily available) or a typewriter to write password suggestions. The mechanical part would be tricky, because the hammers require some force to be actuated (and I would find it criminal to destroy a vintage typewriter for that).

This is pleasingly insane, congratulations! Is there a program to test the fairness of a given dice or coin? Is that a program that's even feasible to write?

You can measure the Shannon entropy of a sequence

....you can do that using our universe's physical constants too.

Care to elaborate? Or link?

I mean, everything that is, is just displaced temporarily homogeneous complexity, allowable between the fluctuations of gradients of temperature, allowing the illusion of work to appear more than just energy dissipating into the either of expanding space-time, dragged by the irreconcilability idea of "gravity".

But that doesn't help bake an Apple pie from scratch, as Carl Sagan would put it.

https://stackoverflow.com/questions/990477/how-to-calculate-...

I love the slow pace of the video, including a few minutes presentation of all available programs. And indeed, there are programs to test dice and coin bias:

* https://youtu.be/bJiOia5PoGE?si=IEhbNJk0C0-7_2Nj&t=229

* https://youtu.be/bJiOia5PoGE?si=3Se3lYFVAAkElx0w&t=245

You've always got the standard way to get fair random numbers from a fairness-unknown coin. Flip it twice. Restart if you get both heads or both tails. If you get H then T or T then H, those are equally probable, so take the first one of those as the final outcome.

This generalizes to a die of N sides. Roll it N times. If you don't get all N distinct results, restart. If you do, then take the first result as your final outcome.

(That may take a lot of trials for large N. It can be broken down by prime factorization, like roll 2-sided and 3-sided objects separately, and combine them for a d6 result.)

Hmm my intuition isn't agreeing with this. Does this have a name so I can read more about it?

Von Neumann randomness extractor

https://en.m.wikipedia.org/wiki/Randomness_extractor#Von_Neu...

I have the humility to admit that this, despite everything I pretend to know, has always escaped my understanding.

Someone please (jump?) at the chance to explain this one to me.

(assume i failed 9th grade 3 times)

The key assumption is that T and H may not have the same probability, but each flip isn't correlated with past or future flips. Therefore, TH and HT have the same probability. So you can think of TH as "A" and HT as "B" then you repeatedly flip twice until you get one of those outcomes. So now your coin outputs A and B with equal probability.

I feel like I am missing something so obvious that I feel the need to correct wiki, but that likely means I am fundamentally missing the point.

"The Von Neumann extractor can be shown to produce a uniform output even if the distribution of input bits is not uniform so long as each bit has the same probability of being "one"->[first] and there is no correlation between successive bits.[7]"

As long as the person doesn't favor which of the two bits they chose is "first", then it should appear as random.

But that is self-defeating, as if the person had the capability to unbiased-ly choose between two binaries, they wouldn't need the coin.

But since the only way to determine the variation from expectation is repeatedly increasing sample size, I don't see how doing it twice, and just taking encoding of the bits, then...

Is the magic in the XOR step? To eliminate the most obvious bias (1v5 coin), until all that could had been left was incidental? Then, always taking the first bit, to avoid the prior/a priori requisite of not having a fair coin/choosing between two options?

and it clicked. Rubber duck debugging, chain of thought, etc.

I will actually feel better now.

>To eliminate the most obvious bias (1v5 coin), until all that could had been left was incidental?

There is only one coin, flipped _twice_; not a running occurrence, but in couples, perfectly simulating two coins functionally.

Once a literal couple of coins result in a XOR'd result eventually, no matter how biased - they differ - the exact ordinality of which will be random.

Two sides to a coin, no matter how random, still half the chance.

(for lurkers cringing at my subtle mis-understanding)

Maybe I don't understand why or what you don't understand but...

Say you have a biased coin. It lands heads 55% of the time (but you don't know that.) Then the probabilities are:

HH = (0.55 * 0.55) = 0.3025

TT = (0.45 * 0.45) = 0.2025

HT = (0.55 * 0.45) = 0.2475

TH = (0.45 * 0.55) = 0.2475

If you disregard the HH and TT results then the equal probabilities of HT and TH result in a perfect binary decider using a biased coin. You assign HT to one result and TH to the other.

  >Maybe I don't understand why or what you don't understand but...

Small mis-step because of an extremely bias head-example (99%H, 1%T).

When imagined, the first result is 99% Heads...until you finally flip a Tails.

We had to do this exact thing in 6th grade, and I picked proving 5%...fml.

I forgot that they are discrete pairs, not continuous (like my head cannon).

The XOR is the magic. Always has been.

Maybe this intuitive "proof" will help.

Coins and dice and datums (solid objects with detectable outcomes) may, or may not have bias, it depends on how they were made and on manufacturing defects that resulted. But, at a minimum, such bias can oftentimes be side-stepped or bypassed.

Consider this argument from Johnny Von Neuman.

Suppose you have a single biased coin with these outcome probabilities:

A) Heads (1) 60% (Call this probability p.)

B) Tails (0) 40% (The probability of this outcome is q=(1-p), by definition.)

Now let us apply this algorithm to sequential tosses for this coin:

1) Toss the coin twice.

2) If you get heads followed by tails, return 1. (Say this outcome occurs with probability p’.)

3) If you get tails followed by heads, return 0. (The probability of this outcome is q’=(1-p’), by definition.)

4) Otherwise, ignore the outcome and go to step 1.

The bit stream that results is devoid of bias. Here’s why. The probabilities of obtaining (0 and 1) or (1 and 0) after two tosses of the coin are the same, namely p(1-p). On the other hand, if (1 and 1) or (0 and 0) are thrown, those outcomes are ignored and the algorithm loops around with probability 1 – 2p(1-p). So, the probability (p’) of getting a 1 using this algorithm after any sequential two tosses of the coin is p’ = p(1-p) + p’(1-2p(1-p)). The solution of which is p’=1/2, and since q’=(1-p’), then q’=1/2. A fair unbiased toss!

In fact, the example bias numbers given above don’t matter for the argument to hold (note that after solving for p’ it is independent of p). The outcome of the algorithm is a fair toss (in terms of the (0 and 1)-bit stream that results), regardless of the actual bias in the coin for a single toss. All the bias does is have an effect on the efficiency with which the bit stream is created, because each time we toss heads-heads or tails-tails we loop around and those two tosses are thrown away (lost). For an unbiased coin the algorithm is 50% efficient, but now has the guarantee of being unbiased. For a biased coin (or simply unknown bias) the algorithm is less than 50% efficient, but now has the guarantee of being unbiased.

This algorithm is trivial to implement for the Satoshi9000.

Thank you so much for explaining it with a concrete example, now even I understand it :)

This really is a useful idea.

It may be more likely that H or T happens (an unfair coin), but in a pair of H and T, both HT and TH are equally likely. Therefore which is "first" is equally likely H or T.

Only holds if no spooky effects change results based on last result. (like a magic die that counts upwards or a magic coin that flips T after H no matter what)

P(TH) = p(T)*p(H) = P(HT)

Your second paragraph is correct and may be where the previous poster's intuition was disagreeing, that the method doesn't necessarily hold for repeated iterations in a physical system where one trial starts from where the last one ended.

It's not even really "spooky" - all you need is a flipping apparatus that's biased towards an odd number of rotations, and so then THTH is more common than THHT and you get a bias towards repeating your last result.

Exactly right, I was thinking an unfair coin could have "memory" but then the method doesn't hold.

What about a 'dirty' coin or dice, where the dirt falls off during the run?

That'd do it.

P(H|N) != P(T|N)

And

P(H|N) != P(H|N-1) (and visa versa)

Means that

P(HT) = P(H|N-1, T|N) != P(TH)

That's a clever point. But I think a corner case.

I suspect that when the user is loading coins or dice in the machine, they would notice any dirt that was significant enough to look as though it might be a problem.

And oil deposits from your fingerprints I would imagine are so minuscule as to be insignificant in creating varying bias.

Even then, in both cases, you could wipe the objects with an alcohol swab before putting them into the shaker cups.

It could be argued, I suppose, that every micro-collision of the coin or die with the cup removes a few atoms, but I would suggest that its effect on the bias of the coin or die over time is again minuscule. Indeed, unmeasurable over a full sequence of cycles (128 for example) of the machine when generating a Bitcoin key.

But an interesting point. Keep 'em coming!

Virtually everybody is using the BIP-39 / BIP-44 protocols to derive addresses from a 256 bit (or 128 bit) key.

If you have a way to generate 256 bit, you have a way to generate a Bitcoin (or Ethereum or whatever) wallet.

Some people trust their hardware wallet to generate a random 256 bit / 24 words (each word is 11 bit as the dictionary contains 2048 words: 24 words is 264 bits, 256 bit + 8 bit of checksum).

But others do it manually, in an analog way.

One way to do it to throw a 16-sided dice repeatedly: that's a good source of entropy. That's entirely analog.

BIP-39 has a checksum (4 bit for 128 bit keys and 8 bit for 256 bit keys), so you'll need some code to either find or verify the checksum. To do that people are typically going to use a fully offline/airgapped computer: for example an old desktop, without any Wifi capability, booted without any harddisk, from a Linux Live CD (I know, I know: you'll read their key from the electrical activity by tapping the electrical circuit outside their house or by firing a laser at their window, so it's not "fully airgapped": bla bla bla).

From that single 256 bit number you can derive wallets for all the coins you want.

Once people have generated their key by throwing dice, they'll typically store their key behind a HSM, on a hardware wallet. And the private key never leaves the hardware wallet (but can be used to sign transactions). And a "paper" copy of the key typically also lives in the analog world (and listen to Gandalf: "keep it safe", "keep it secure").

The video is definitely cool but creating a key in the real (non digital) world is something quite common.

Truth be told, that is exactly how I used to generate my crypto keys.

I would take 256 quarters (sometimes fewer and accept that some might be tossed more than once) and toss them to get ones and zeroes. Tedious, and somewhat error prone (see below). Then do the calculations by hand, also somewhat tedious and error prone.

There is plenty of research that demonstrates that humans are poor at tossing coins in an unbiased way. People cheat (especially if money hangs on the outcome) and people are also lazy, so that the first toss is vigorous and diligent, and so the coin tumbles end-over-end many times before coming to rest for a result (heads or tails), but after several hundred tosses, the vigor and diligence are gone and the coin barely leaves their hand.

Part of my motivation in building the Satoshi9000 was to automate this manual process and at the same time take out human bias. Which is to say, automate away the human part and automate the math of key generation. But at the same time, make it secure by having the machine air-gapped (that is, no connection to the outside world beyond a power cord) with the ability to walk-away with anything that might leave a clue as to how, why and when the machine was last used; what I refer to as "walk-away randomness" in the video. After removing the coins, SD cards (OS and user programs) and printout, what is left is little more than a motor and some wires. An adversary looking to recover your keys would have no clue as to whether the machine had ever been used, yet alone what for. Maybe it was simply used to generate a quick-pick for tomorrow's drawing of Powerball. You would have now way of knowing.

(As an aside, you could even walk away with the remaining paper roll from the printer, so an adversary would not even know how much had been printed! Also, the printer uses no ink and has no buffer/memory, which was a deliberate choice in the design.)

Love this. Is the private key printed on a separate piece of paper? I saw only #####'s. How long does it take to generate a full key using dice?

For the demo video I had the printer output the key-pair twice. Once with the private key in plain (visible) text, and another for the demo video with the private key replaced with ######'s.

I didn't think it wise for a public demo video to show everyone the private key!

Just like every aspect of the operation of the Satoshi9000, printer output is fully under the control of the user program. I simply put a "PAUSE(hit run to continue)" command between printing the key-pair properly, and printing the key-pair with the private key hashed out (the one visible in the demo video). The "PAUSE(hit run to continue)" appears in the "Log File/Debug" window while the program is paused.

The bit rate of the machine is around 4-bits per minute (time length of tossing/shaking is wholly under the control of the user - can be longer per shake), so for a 256 bit key it takes around an hour. But remember, Bitcoin keys are forever (or the remaining lifetime of the Universe, whichever is shorter), so taking an hour to generate it is short in comparison to its useful lifetime.

I hope that helps.

Thank you for this extensive answer. Eager to see what kind of inventions and improvements you come up with in the future.

Best use case I can think of is replacing the die roller in the board game trouble.

“You can pop a lot of trouble in the pop o matic bubble”

It would be nice to access it from /dev/random on a normal machine (at a very slow bitrate)

I like that idea. Someone also pointed out that it could be a live video feed online. Just take the bits (in pairs, left and right shakers, or singly, just left or right shaker, or some alternating choice of the two) you need in the way you want. As I say, I like the idea of making the random bit-stream available to users.

And, as you point out, given it generates randomness by tossing physical objects, it is naturally a low bit-rate machine.

Love it. I wonder what the distribution of rolls/tosses for this looks like. This also reminds me of an automated dice roller thingy that someone built with a hopper of dice, a conveyor to bring the dice to the top of a ramp and ocr to record all of the rolls, a "Dice-o-matic" [0]. And a vidja of it in action [1].

[0] http://gamesbyemail.com/news/diceomatic

[1] https://www.youtube.com/watch?v=7n8LNxGbZbs

On an historical note, ever since dice and coins have been used by humans (thousands of years), there have been efforts to "automate" their tossing in an effort to make the toss or roll fair (unbiased). See, for example, the Vettweiss-Froitzheim Dice Tower, https://en.wikipedia.org/wiki/Vettweiss-Froitzheim_Dice_Towe...

The reason is simple. Humans are terrible sources of randomness. Especially true if money hangs on the outcome!

There are two principal components for bias of a coin or die toss/roll: 1) the coin or die itself (manufacturing defects, etc.), which if it exists is typically minuscule, and 2) the act of tossing or rolling by a human (a twist of the wrist, or a flick of the fingers), whose bias is enormous and which, as I say, is particularly pronounced if money hangs on the outcome.

The Satoshi9000 solves problem 2, the human element, by removing the human from the process altogether. Other than to press the "run" button.

This concept reminds me of the cloudflare lava lamps! Awesome!

I love the well executed combination of (electro-)mechanics and computing. Rare to see talent in both combined in one person. The printing of the result in the end is particularly charming.

Not sure, if there would ever be a mass market for such, but I can totally see it (or something similar) generating lotto numbers live on t.v. .

I would argue that the future belongs to people who can actually make useful things! If we revert to cave dwelling (which perhaps we might given the way things are going!), then being able to flake flint tools might be a far better skill to have than being a social media "influencer".

And today, most physical products require a combination of mechanical, electronic and programming skills. Fortunately, I have all three. I suggest people likewise diligently acquire all three.

It's also fun to build useful machines.

I worked in banking all over the globe for 30 years. I did not acquire my useful skills in that profession. Money yes. Useful skills no.

I acquired my mechanical/electronics/software skills long, long ago while a postgraduate in experimental physicist at Oxford, building space instrumentation. Why did I go into banking then, you ask? Poverty is the answer!

I found the video very entertaining. Very old-school. And boy, you’ve paid a lot of attention to the device. It looks very pro.

A bingo cage or lottery machine could probably be made to do a similar task (just need a mechanism to return the balls to the machine after each drawing).

Anyway, quite charming!

Reminds me of the codex32 project: https://www.secretcodex32.com/

How does it read the value from the coins or dices?

At 5:44, the vid shows a webcam facing up to photograph the bottom of the coin/die through the shaker window. I guess there's some CV to read the item.

Correct.

Beautiful <3

This looks interesting, but there are much better (higher bitrate) sources of pure randomness, and I'm not sure what advantage this has over those. If I don't trust the machine that's generating the randomness, that doesn't only apply to the randomness component, I similarly mistrust this machine's code, the hardware, etc.

I'm not sure what this would add over, for example, entropy derived from a hash of the image of a camera's thermal noise profile.

I'm not sure what advantage this has over those.

Those usually don't look and sound like they were made by Doc Brown.

Well said. I find the creator did a delightful job in his presentation. So much pride in the craftsmanship visible in his presentation as well as the finished product. I subscribed and hope for more videos..

it's simple

I think the advantage of this one is that it's funny. :)

I didn't watch the video because I didn't have sound, if it's meant to be funny, then I applaud it.

It's a very serious video, which adds to the comedy of it.

The Satoshi9000 makes only one claim as a value proposition.

Value proposition: The key value proposition of the machine is that it generates analog randomness in the physical world and converts it into digital (1’s and 0’s) randomness. Especially noteworthy is that it can do so in a visibly, and to a lesser extent audibly (the sound of an agitated coin or die), way that is easily recognized and understood by humans. Other ways of generating digital randomness do not have this characteristic and in some ways have to be considered opaque to the public at large in their method of generating randomness. It comes down to whether people trust their eyes more than a black-box and whether people want this characteristic when generating randomness they are going to use.

I venture to say that anyone, from 5 years old and upwards who saw the machine in operation would understand how it is generating randomness. Dice from prehistory have been used by humans to generate random outcomes, and from the first millennium BC, when coins arose, the same can be said of coins.

Consider a randomized clinical trial. You may have patients that are not technically sophisticated, but must be convinced that the randomized aspects of the trial are done in a way they understand and are willing to give their consent. The same can be said for lawyers.

"I'm not sure what this would add over, for example, entropy derived from a hash of the image of a camera's thermal noise profile." Do you think a 95 year old grandmother will understand the principles by which this type of randomness is created?

Mistrust the machine? Then simply don't use it. ("Don't trust them lying eyes!") What I can say in its favor is it's connected to nothing (air-gapped), you fully control every important aspect of the randomness (fully programmable). Don't like the coins you have? Simply take a quarter from your own pocket and put it in the shaker. Don't like the microcontroller provided, buy (for $4) your own and plug it in. Ditto for the other components. All sensors, motor etc. are commodity parts; replace them. I think this machine is more provably back-door free than any cryptographic machine out there. As I point out in the video, all they important parts used in the generation of randomness walk-away in the palm of your hand -- what I call "walk-away randomness" in the video -- and all that's left is a motor and some wires.

As to the bitrate. Yes, it is not a high bitrate machine, the bit rate of the machine is around 4-bits per minute (time length of tossing/shaking and vigorousness of shaking is wholly under the control of the user - can be longer per shake, faster or slower, or variable during the shake), so for a 256 bit key it takes around an hour. But remember, Bitcoin keys are forever (or the remaining lifetime of the Universe, whichever is shorter), so taking an hour to generate it is short in comparison to its useful lifetime.

I hope the detail, and some background, helps.

So, to generate a random bitcoin key, that's how many coin tosses or die tosses?

The video says 128 cycles. Each cycle is 30 seconds, so it would take 64 minutes.

This is cute, I like it

During the cold war, the Washington-Moscow "nuclear" hotline was set up with teleprinters and one-time pad keys for both directions. I imagine they had an analogue randomness key generator on both ends to generate the key material.

Presumably they're using ~Dual-EC DRBG~ some kind of quantum randomness generators these days.

There was, interestingly, a much fancier system used quite a bit earlier

https://en.wikipedia.org/wiki/SIGSALY

https://news.ycombinator.com/item?id=20138230

> The noise values used for the encryption key were originally produced by large mercury-vapor rectifying vacuum tubes and stored on a phonograph record.

That's sure a hardcore way to run an analogue randomness generator.

The beta decay enthusiasts were busy elsewhere.

Cymru am byth!

Yma o Hyd!

I started my working life at age sixteen as a coal miner at the Deep Navigation Colliery in South Wales.

Today, building useful and interesting machines has a lot in common with coal mining. A lot of hard work, and the perpetual risk of being crushed to death by 1,000 feet of rock above you. (The last part is perhaps a bit of a stretch, but it oftentimes feels that way!)

i love everything about this, including the absurd impracticality. which i, personally, would call "art".

awesome.

Why the thermal printer? The text fades eventually and you will lose your private keys.

Yes it really ought punch brail or something?

There is another slot below that reads "archival grade printer".

Correct. But it does allow you to walk-away (with other stuff from the machine) with the keys immediately after generating them, leaving a machine which is little more than a motor and some wires at that point.

So what I typically do is print a warning at the top and bottom of the printout urging the user to transcribe the important parts using archival paper and pen as soon as they can.

Also, if you look at the video, you will see an "Archival Printer" port on the front of the control box because I’m developing a printer that prints the keys (plus QR codes) on metal so they last for decades and perhaps centuries. That may be useful in estate planning where the key may be locked away in a safe, or a lawyers safe, for generations. But transcribing to archival paper and pen is relatively permanent (decades) and is easy and seems to work well (lawyers like it).

I think the cloudflare video wall is a more practical way to mass generate entropy but this is suitably madcap I enjoy it. There are also other existing methods but they're not as... clearly demonstrable... as this like is used in existing hardware TRNGs.

https://en.wikipedia.org/wiki/Hardware_random_number_generat...

The Cloudflare lava lamp wall isn't actually that practical. You get more randomness with the lens caps on the cameras (i.e. where the whole frame is just thermal noise).

It's not the simplest possible but it's more practical than this by miles. It's a continuum.

The case I would make for the Satoshi9000 is that its method of generating randomness is intuitively understood by anyone from five years old to ninety-five years old, technical or non-technical.

I think it would be a stretch to think you could pull a random person off the street, point to a wall of lava lamps, and ask "do you see the randomness, how does it work?" Whereas, I think if you pull a random person off the street, let them watch the Satoshi9000 do its thing, and ask "do you see the randomness, how does it work?" you might get an answer that makes sense.

That, in a nutshell, is the value proposition behind the Satoshi9000.

People are missing the point that it is creative and gets the job done, conversation pieces can go a long way.

Am I missing something? There's not a single negative comment in the post as of now.

Well... I think the comments are mostly "this is insane and great". I guess you could view the insane part as negative if it was intended to be serious. Kind of hard to tell tbh!

Those sentiment-analysis comments ("HN hates X", "it's sad people have to be so negative") really irk me.

Likely thousands of HNers viewed the link. 100+ upvoted. A couple of random accounts (individual(s)? bots?) leave similar comments.

And then somehow those comments are supposed to reflect a wider sentiment of some community or population?

This comment brought a smile to my face.

When I showed the machine to my son, Nate, a mechanical engineer, he thought it looked like something from a 1950's sci-fi movie like "Forbidden Planet". Back then, plastics were high-tech and new, and with the acrylic domes, the Satoshi9000 would not look out of place on the set of that movie.

He suggested that every coffee table should have one!

I am super dubious of mechanical systems for randomness... Newtons laws are fully predictable after all...

I suggest that any system like this has the output XOR'ed with another random source. If two random sources are XOR'ed together, then both need to be predictable for the output to be predictable.

> Newtons laws are fully predictable after all...

Not fully actually:

https://plato.stanford.edu/entries/determinism-causal/#ClaMe...

There are two coins or die being flipped here. I am guessing they likely use the von Neumann trick for getting random data from biased sources

https://en.wikipedia.org/wiki/Fair_coin#Fair_results_from_a_...

That algorithm requires using the same coin for both tosses.

good catch!

Correct.

But that only requires you to run the machine with the same coins/dice in the shakers for two consecutive cycles. And to repeatedly do so into you have generated the desired length of 0/1 bit stream.

Bear in mind the machine is fully configurable/programmable. You always choose what goes into the shakers, how many cycles are run, for how long they shake, how vigorously they shake, and what are done with with the 1's and 0's that result.

Implementing Von Neuman's algorithm on the Satoshi9000 is trivial.

Sure. But you can't run it at 1 bit per cycle, only at 2 bits per 2 cycles.

i think you should check your work with this comment a bit... (ok more than a bit)

what is the point in having a source of randomness if you need to XOR with a random source? relatedly, if you have a source of randomness, (1) please share and (2) well, there's no real need to go down this particular rabbit hole at all, well, is there?

independent of all of that, you seem to be anthropomorphizing the XOR function a bit... sure, there are some contexts where "1"s "mean" something and "0"s don't (sparse coding? and yeah, that is some pretty generous contortion, but hey: we're all friends here, right?), but in the case of "randomness"* the whole point (presumably) is that predicting "1"s and predicting "0"s are both exactly the same thing: Sisyphean.

i'm not sure that the word "random" "means" any thing beyond "distribution that we cannot model". which is a fine definition, given that models are how we attack random number generation...

* mind you i challenge the reader to pray tell what "randomness" even really means in anything other than a pseudorandom context (aka used to justify the randomness of various algorithms). isn't it oddly instructive that we use something that would pass as a proxy for "random"ness as the basis for our official definition for the second? (Cesium-133). the "second" is no more real than it is random. random is defined via a threshold of non-randomness, and all that we value as discrete and integral in the world that exists beyond our minds (-- if it does, in fact, even exist (or even "exist")--) is a house built upon sand. well, worse than that: the universe "works" because Avogadro's Number is a hell of a lot closer to infinity than it is to zero, and that's good enough for me. log(N) < 100.

Side note: excellent unintentional ASMR once Andrew starts explaining how the machine works.

Are these like public randomness beacons? NIST[0] and Cloudflare[1] have them. I guess use cases are lotteries that are publicly verifiable, election auditing...

[0] https://csrc.nist.gov/projects/interoperable-randomness-beac...

[1] https://drand.love/

[2] https://blog.cloudflare.com/league-of-entropy/

No.

Election auditing.

That's a quite interesting idea. I will put more thought into that.

Thanks!