[HN Gopher] Show HN: Satoshi9000 analog BTC key generator (mecha...
___________________________________________________________________
Show HN: Satoshi9000 analog BTC key generator (mechanical)
I built this machine so I could generate Bitcoin keys that I could
trust. Air-gapped and simple to use and understand (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?
Author : AJTSheppard
Score : 150 points
Date : 2024-10-23 22:26 UTC (1 days ago)
| stavros wrote:
| 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.
| pvg wrote:
| _I 'm not sure what advantage this has over those._
|
| Those usually don't look and sound like they were made by Doc
| Brown.
| beng-nl wrote:
| 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..
| qqqult wrote:
| it's simple
| tylervigen wrote:
| I think the advantage of this one is that it's funny. :)
| stavros wrote:
| I didn't watch the video because I didn't have sound, if it's
| meant to be funny, then I applaud it.
| jjk7 wrote:
| It's a very serious video, which adds to the comedy of it.
| KaiserPro wrote:
| This is cute, I like it
| whs wrote:
| How does it read the value from the coins or dices?
| imglorp wrote:
| 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.
| ducknorris wrote:
| Beautiful <3
| hggh wrote:
| Why the thermal printer? The text fades eventually and you will
| lose your private keys.
| willvarfar wrote:
| Yes it really ought punch brail or something?
| jszymborski wrote:
| There is another slot below that reads "archival grade
| printer".
| dools wrote:
| 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"
| nodlek wrote:
| People are missing the point that it is creative and gets the job
| done, conversation pieces can go a long way.
| fkyoureadthedoc wrote:
| Am I missing something? There's not a single negative comment
| in the post as of now.
| IshKebab wrote:
| 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!
| 3np wrote:
| 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?
| mattbee wrote:
| 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?
| jdmoreira wrote:
| You can measure the Shannon entropy of a sequence
| Jerrrrrrry wrote:
| ....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.
| t0mek wrote:
| 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
| vikingerik wrote:
| 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.)
| eddd-ddde wrote:
| Hmm my intuition isn't agreeing with this. Does this have a
| name so I can read more about it?
| shmageggy wrote:
| Von Neumann randomness extractor
|
| https://en.m.wikipedia.org/wiki/Randomness_extractor#Von_Ne
| u...
| Jerrrrrrry wrote:
| 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)
| voldacar wrote:
| 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.
| Jerrrrrrry wrote:
| 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.
| jvanderbot wrote:
| 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)
| vikingerik wrote:
| 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.
| eddd-ddde wrote:
| Exactly right, I was thinking an unfair coin could have
| "memory" but then the method doesn't hold.
| ajay-d wrote:
| 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/
| RIMR wrote:
| No.
| red_admiral wrote:
| 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.
| pvg wrote:
| 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
| red_admiral wrote:
| > 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.
| pvg wrote:
| The beta decay enthusiasts were busy elsewhere.
| rtkwe wrote:
| 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...
| duskwuff wrote:
| 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).
| ape4 wrote:
| It would be nice to access it from /dev/random on a normal
| machine (at a very slow bitrate)
| chungus wrote:
| 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?
| londons_explore wrote:
| 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.
| cubefox wrote:
| > Newtons laws are fully predictable after all...
|
| Not fully actually:
|
| https://plato.stanford.edu/entries/determinism-causal/#ClaMe...
| jszymborski wrote:
| 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_...
| fluoridation wrote:
| That algorithm requires using the same coin for both tosses.
| keeganpoppen wrote:
| 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.
| raverbashing wrote:
| So, to generate a random bitcoin key, that's how many coin tosses
| or die tosses?
| darkstar999 wrote:
| The video says 128 cycles. Each cycle is 30 seconds, so it
| would take 64 minutes.
| theideaofcoffee wrote:
| 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
| jejeyyy77 wrote:
| awesome.
| freeplay wrote:
| Side note: excellent unintentional ASMR once Andrew starts
| explaining how the machine works.
| renewiltord wrote:
| 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.
| abotsis wrote:
| This concept reminds me of the cloudflare lava lamps! Awesome!
| robinduckett wrote:
| Cymru am byth!
| rbanffy wrote:
| 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).
| keeganpoppen wrote:
| i love everything about this, including the absurd
| impracticality. which i, personally, would call "art".
| Razele wrote:
| Reminds me of the codex32 project: https://www.secretcodex32.com/
___________________________________________________________________
(page generated 2024-10-24 23:01 UTC)