Posted by AJTSheppard 10/23/2024
Show HN: Satoshi9000 analog BTC key generator (mechanical)
The Satoshi 9000 demo: https://youtu.be/bJiOia5PoGE
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. Seamlessly.
But it occurs to me that it may have other uses beyond crypto keys for your own use, such as: * Randomized clinical trials. Clinical trials need a high degree of transparency for ethical reasons; also, for legal reasons should it come to light after the trial has ended that patient selection and treatment selection was not random or in some way biased (say, by the researchers themselves). The machine described herein can provide that transparency to young and old patients, technical and non- technical. * Non-technical management. Many network engineers in need of security keys have bosses that are non-technical. Such managers might prefer security keys (and their generation) which are easier for them to understand. * Estate planning. Suppose members of a family were to inherit digital assets (such as Bitcoin, for example). Not all members of the family are technical and understand Bitcoin. However, each will still need to generate a secure Bitcoin key to receive their share of the inheritance. The machine described herein might help in that task because its source of randomness is more easily understood by laypeople and each can generate their own private key in private (in isolation with the machine). * Anywhere where the users have to have an intuitive understanding of how the randomness is being created; whether they are 5 years old, or 95 years old, and all ages in between.
I'm curious to know if any of the folks over at HN can think of other use cases?
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).
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.
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 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.)
https://en.m.wikipedia.org/wiki/Randomness_extractor#Von_Neu...
Someone please (jump?) at the chance to explain this one to me.
(assume i failed 9th grade 3 times)
"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.
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)
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.
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.
This really is a useful idea.
>Maybe I don't understand why or what you don't understand but...
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.
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)
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.
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!
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)
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.
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.
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.)
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.
“You can pop a lot of trouble in the pop o matic bubble”
And, as you point out, given it generates randomness by tossing physical objects, it is naturally a low bit-rate machine.
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.
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. .
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!