[HN Gopher] Show HN: Timelock.dev - Send a secret into the futur...
___________________________________________________________________
Show HN: Timelock.dev - Send a secret into the future using
timelock encryption
This is simply a web interface built on top of the timelock
encryption system posted by Cloudflare last week.
https://blog.cloudflare.com/harnessing-office-chaos
Author : aarreedd
Score : 102 points
Date : 2024-03-10 18:46 UTC (4 hours ago)
(HTM) web link (timelock.dev)
(TXT) w3m dump (timelock.dev)
| lucb1e wrote:
| The only way that I know to encrypt something into the future is
| generating an N-bit key and hoping someone will go through the
| trouble of cracking it when that becomes feasible. That involves
| lots of assumptions (e.g., how computing power develops and how
| much that person cares).
|
| The website's implementation is this:
|
| > A group of [orgs] holds the keys. There are 18 separate
| organizations running a total of 22 nodes, with a threshold of 12
| needed to release a secret.
| buu700 wrote:
| That's an interesting idea. Similarly, you could make a sort of
| quantum time capsule by encrypting a blob of data with RSA or
| ECC and publishing the cyphertext alongside the public key. You
| could even adjust the key size depending on how powerful you
| want the quantum computer that decrypts it to be.
| dheera wrote:
| The problem with "feasible" is that the time precision is poor.
| Feasibility is modulated by the value of the secret. If the
| secret exposes $1 billion in value, people will happily throw
| $100 million worth of compute at it.
|
| I'm not an expert on DeFi but could we do something more time-
| precise using the Ethereum blockchain and a smart contract?
| lucb1e wrote:
| > could we do something more time-precise using the Ethereum
| blockchain and a smart contract?
|
| I think only if you want a transaction to move forward at a
| certain time, and are confident that a majority of network
| members will not conspire to alter your smart contract.
|
| Hiding information in a smart contract: I don't know of a way
| that could be done, but I'm not up-to-date on this stuff
| either (I left that scene after Bitcoin outgrew the tech demo
| phase and became popular as a "so long as a majority keeps
| buying and holding, everyone's coins are worth insane
| amounts!" scheme)
| Groxx wrote:
| You might be able to implement this same kind of "have N
| cooperating message-senders that agree to do X at time Y or M
| of them can prove violation and penalize [probably
| everyone]", but you still need _information that is not
| available until time Y_. People / systems need to hold onto
| but not reveal that information until that time.
|
| This is basically weaponized (and possibly automated)
| enforcement of a rule. It's not crypto, it's just "agree to
| this or you get the lead pipe". Lead pipes are _extremely
| useful and valuable_ and this is a completely reasonable
| tradeoff in a huge amount of situations, but it 's not a
| _true barrier_.
|
| To get around the lead pipe requirement, you need some kind
| of data that exists but is _technologically or physically
| inaccessible_ until time Y. Ethereum has no primitives like
| that because nobody has primitives like that. About the
| closest you get is to say "crack this public key to get the
| reward" and, yea, that's effectively time-lock encryption
| (it'll Y years with all the hardware in the world so it's
| "locked" for at least that long at 99% confidence or
| something) but nobody really considers it "time locked"
| unless you are intentionally designing a key to take Y time
| under Z hardware assumptions (which does exist, but a 1-PC-
| year key takes seconds with enough hardware).
| lucb1e wrote:
| I don't understand the lead pipe analogy. What's up with
| getting a metal pipe if you don't "agree to keep this
| secret"?
| Groxx wrote:
| It's just one of many tools commonly used in the
| https://xkcd.com/538/ meme.
| lucb1e wrote:
| Oh it's a way of saying "killed", or at least that
| something inconvenient will happen for/to you. Got it
| pcthrowaway wrote:
| Not with ethereum or a smart contract, because any ethereum
| node can simulate any execution of a smart contract.
|
| But it occurred to me that you can _sort of_ do something
| like this with a proof of work-like algorithm, though the
| time to solve would still be variable.
|
| Essentially you'd need a network of "miners" and instead of a
| block, you'd have a node encrypt a message with an encryption
| key of a set difficulty (decryption key length), based on the
| target decryption time and the network hash rate (hash rate
| probably is not the correct term, but I'll use it for
| conciseness).
|
| The miners would then work to decrypt the data using the
| knowledge of the key length.
|
| I'm not sure how you would incentivize the miners to work on
| decrypting it though, and the node which encrypted it would
| of course have knowledge of the message, so I don't see how
| this could be used in practice.
|
| In theory if your miners were running something like a
| tamper-proof secure enclave (I'm not even sure if these truly
| exist) perhaps there's a way to attest their own hashrate,
| and then an encrypted message can be proposed by a node to a
| subset of miners which collectively have the assumed
| hashrate. The secret-encrypted data can then be re-encrypted
| for each miner, with their public key.
|
| This ensures other miners not participating in the challenge
| can't attempt to decrypt the data.
|
| The problem here is incentivization over a long period of
| attempting to decrypt the data. You'd have to offer a reward
| large enough to incentivize the miners to cooperatively work
| to decrypt the message for the longest possible amount of
| time it could take to decrypt the message.
|
| edit: I think for this to work you'd _first_ need to encrypt
| the data for each miner which should participate in the
| challenge, and _then_ encrypt it with the secret key. That
| way a miner which solves this can publish the decryption key
| and the still-encrypted payload, which only they can decrypt,
| and all the other miners can apply the same solution to
| verify the published solution and solved message with their
| own private keys.
|
| edit 2: I suspect there's something potentially useful here,
| but I don't know enough about secure enclaves to really know
| if it's feasible to implement in a way that prevents gaming,
| so if someone knows more about such things, feel free to take
| the idea and run with it.
| FriedPickles wrote:
| You could create a DeFi system not too unlike the one linked
| in this post: a number of oracles release keys at designated
| times (use M of N encryption).
|
| The oracles could be financially incentivized to behave
| properly. E.g. they post a bond, which is confiscated if they
| don't post a private key on time or if a whistleblower
| discovers and reports a key early. In return for correct
| behavior they can earn some fees paid by users of the
| service.
|
| The financial incentive still flips if the secret's value is
| sufficiently large, but it would require coordination of many
| unprincipled oracles.
| dheera wrote:
| The problem with whistleblowers is that now the entire
| system's security is transferred to them. Whistleblowers
| can also be bribed to blow whistles early or not blow
| whistles.
|
| Here's an another idea. Bitcoin has a halving, right?
| Somehow the entire system has agreed to halve at a certain
| time, and not halve early or halve late? How does this
| work? Can we utilize this time agreement somehow? Can it be
| incorporated into an algorithmic whistleblower, whereby (a)
| N people each know 1/N of the key (b) if anyone
| demonstrates that they know the answer to a question before
| halving, whistles are blown by a contract and all N people
| are punished (c) after halving, all N people receive a
| reward?
| Groxx wrote:
| Anyone can halve at any time, so anyone can "cheat" that
| by halving immediately.
|
| The reason everyone does it at the same time is because
| doing it [literally right now] will lead to a history
| that nobody else agrees is valid (halved at the wrong
| block number), so any coins you mine on your forked chain
| will be worthless. There's a _monetary_ incentive to play
| by the rules, but absolutely no _technical requirement_.
|
| Bitcoin's primary achievement (IMO but it's fairly
| common) is that it managed to design a technological
| system that _encourages_ playing by the rules. Cheating
| always pays worse than playing along, and even trolling
| only works if you have the majority of all computing
| power (very expensive), so there 's no reason to cheat.
| But outside the core public key cryptography that handles
| addresses and proving transactions, and the "proof of
| work" that basically just limits the speed of everything
| so there's time for the world to agree on things, there's
| not really any fundamental crypto involved. Just self-
| reinforcing social incentives.
|
| (this kind of disagreement is why there's both Bitcoin
| and Bitcoin Cash. they share a common beginning but
| branched off some time ago and are now completely
| separate)
| FriedPickles wrote:
| The whistleblowers are not designated parties, they are
| just any Ethereum user. They would have a financial
| incentive for whistleblowing, and they could never
| falsely whistleblow because the smart contract can check
| whether they actually have the private key early or not.
| charcircuit wrote:
| It's also tough to find good algorithms where you can't just
| spend double to half the time until it unlocks.
| dave1010uk wrote:
| There's not many.
|
| The Rivest, Shamir, and Wagner time lock algorithm is an
| example of one that can't be parallelized.
|
| In theory the NSA and Google can't brute force it much faster
| than you can on a laptop.
| Jamustico wrote:
| Whats the point of this if it's not decentralized/algorithmic
| based.
|
| Who knows if this service will go down or something?
|
| Might aswell just do this with one entity m
| chews wrote:
| HTLC would do the same in a distributed and trustless fashion
| and yet it's important to know League of Entropy is a bunch of
| distributed crypto organizations like Chainsafe or the Ethereum
| Foundation.
| adastra22 wrote:
| I assume you mean a verifiable compute function rather than
| hash time-lock contract, as the latter can't be used for
| encryption. But that's not really a timelock either: it only
| sets a lower bound on the amount of compute required. But
| "compute" here is abstract, and when the conversion from
| "required hashes" to "time elapsed" can vary by 6-10 orders
| of magnitude, it stops having any appreciable meaning.
| wuiheerfoj wrote:
| EPFL, DEDIS, university of Chile, University College London
| and cloudflare aren't crypto organisations
| adastra22 wrote:
| There is no decentralized algorithm for timelock encryption. No
| such scheme exists. Distributed is the best you're going to get
| without a radical breakthrough, and that's exactly what TFA is.
| pjerem wrote:
| Why ? If you wrap the message into multiple layers of
| encryption (TOR style) that needs to go into multiple nodes,
| and if alongside the next encrypted layer you have a date the
| nodes agrees to wait to pass the message to another node,
| that would work, no ?
|
| Even with some corrupted nodes, the message would still be
| secret, the only issue would be if the last nodes are
| corrupted : your message would be distributed too soon. But
| with enough layers and enough nodes to go through, you could
| mitigate this risk.
|
| The network could even detect corrupted nodes if other nodes
| received the message too soon.
| victorbjorklund wrote:
| What stops you from just spinning up X nodes in your own
| private network if everything is open source? And then tell
| every node to decrypt instantly.
| mothepro wrote:
| This is not true at all.
| aarreedd wrote:
| Would love to know how
| troymc wrote:
| Here's a way to encrypt something with an _actual_ timelock,
| which works because physics. More specifically, it works because
| there is a maximum speed that information can travel through
| space: the speed of light.
|
| Step 1: Generate a large number of named public/private keypairs
| and put the private keys on a spacecraft. Also give the
| spacecraft a communication system and a long-lived RTG (an energy
| source getting its energy from the decay of some radioactive
| materials).
|
| Step 2: Send the spacecraft to land on the surface a distant body
| in the solar system, such as one of the moons of Neptune.
|
| Step 3: To encrypt a message such that it's guaranteed to not be
| cracked in less than some specified time, encrypt it several
| times, using the known named public keys.
|
| To decrypt the message, you've got to send it out to the distant
| spacecraft and ask it to decrypt the outer layer of encryption,
| using the private key corresponding to the outer layer's public
| key. It does that and you get back a message but it might still
| have several layers of encryption. Repeat until all those layers
| are removed.
|
| There are tricks to speed things up by sending a spacecraft out
| towards Neptune, but they don't speed things up too much (because
| spacecraft travel much slower than light). The amount of speedup
| possible is left as an exercise for the reader. There's still a
| lower bound on the required time until full decryption.
|
| Inspired by the TOR network.
| dheera wrote:
| > Generate a large number of named public/private keypairs and
| put the private keys on a spacecraft
|
| I suppose, more practically, you could just put the private key
| in an envelope and bury it deep in a shipping container with a
| destination across the ocean. While in transit it's pretty damn
| hard to get to it.
| ttyprintk wrote:
| There are a few geocaching approaches:
|
| Sunken chest / mysterious treasure map
|
| Beacon of high gamma radiation / undesirable to approach for
| many half lives
|
| USB key in Jimmy Hoffas pocket
| lucb1e wrote:
| My inner devil likes the "too dangerous to approach" idea
| :)
|
| About the last idea, I had to look up that name:
|
| > James Riddle Hoffa (born February 14, 1913; disappeared
| July 30, 1975; presumed dead July 30, 1982) was an American
| labor union leader who served as the president of the
| International Brotherhood of Teamsters (IBT) from 1957
| until 1971.
|
| Do I read it correctly if I understand "Jimmy Hoffas
| pocket" to be one implementation example of "any
| disappeared person's pocket"? Or is the specific person,
| their role, or their era relevant?
| ttyprintk wrote:
| You're correct: the fame of discovering Jimmy Hoffas
| burial is high in pop culture. Maybe as high as Hacker
| News finding a usb key timelock where only a vague area
| is given.
| ttyprintk wrote:
| I didn't know his middle name was "Riddle" that's almost
| ironic.
| dustyleary wrote:
| Yes, Jimmy Hoffa is a "famous" disappeared person case
| here in America.
|
| There are only a few "famous mysteries" that became such
| widespread memes in American culture. The ones I can
| think of are:
|
| 1. What happened to Jimmy Hoffa (who killed him?). "The
| Irishman" on Netflix is a Scorsese adaptation of a
| "nonfiction" book that documents an old Mafia hitman
| claiming to have killed Hoffa. (The book is nonfiction,
| the guy's claims are somewhat contested.)
|
| 2. What happened to Amelia Earhart? (Early female aviator
| who disappeared attempting to fly around the world).
|
| 3. What happened to and who was DB Cooper? (A man
| hijacked an airplane, traded some hostages for a duffle
| bag of cash at an airport when such a thing was possible,
| told the pilots to fly to Canada and then jumped out of
| the plane with a parachute and the duffle bag somewhere
| over the pacific northwest).
|
| 4. Who shot JFK?
| ttyprintk wrote:
| Thank you, I regret picking such a reference. Amazing to
| entertain that the guy who killed Hoffa could have lived
| long enough to write about it. As if reality suddenly
| became gentler, and all differences could be hugged out.
| ttyprintk wrote:
| Drone delivers a capsule into an historic minefield / make
| a Great Power clear an area to find it
|
| Sow the hex digits in one crop on top of another / wait
| until summer to see the visible difference
| ttyprintk wrote:
| Slip a key into a random unsolved case file in LA / must
| digitize all files to find it
|
| Choose a key from the DNA of a living Nobel prize winner
|
| Place an opaque nondescript sticker over the lens of a
| surveillance camera in London / must disassemble all
| cameras to find it
|
| Writing Sherlock Holmes level material is not hard
| ur-whale wrote:
| > Send the spacecraft to land on the surface a distant body in
| the solar system, such as one of the moons of Neptune.
|
| The economics of your proposal strike me as a tad weak at the
| knee.
| troymc wrote:
| The up-front capital expenditure might be high, yes, but it
| might be possible to recoup that by charging fees for the
| service once it's working. The Chunnel had a high capex too.
|
| In any case, I just wanted to show that working timelock
| encryption system is theoretically possible. Some people
| claimed it wasn't.
| lucb1e wrote:
| > Inspired by the TOR network.
|
| Because it has such high delays? Basically revealing the
| information which the onion service or exit node encrypted for
| you only after, potentially, a few trips around the globe?
|
| That makes me think this can be achieved without spacecraft, by
| just having geographically distributed private keys (even just
| a few kilometers; you just need the light delays to dominate
| over processing delays).
|
| And I don't think you need more than two keys: if you wrap it
| in A(B(A(B(message)))), then party B cannot work on the first
| layer but first needs to send it to A, party A cannot decrypt
| the second layer but first needs to sent it back to B, etc. One
| of the parties could be your recipient, so that would also work
| with an expensive one-off spacecraft.
|
| > land on the surface a distant body in the solar system
|
| landing is a lot more difficult than staying in Neptune's orbit
| (notice how many moon-bound spacecraft crashed, even only in
| recent years!); you'll get the same characteristics by just
| going out to a desired orbit.
|
| Also note that the amount of delay between Earth and <your
| orbit, such as Neptune's> will vary wildly
| troymc wrote:
| I wrote that the proposed system was _inspired_ by the TOR
| network, not that it literally uses the TOR network. To send
| a message across the TOR network, you wrap it in a bunch of
| layers of encryption, and then each TOR node removes one
| layer: that 's the similar aspect.
|
| Your other critiques are all valid. There's still a lower
| bound on the total time required for full decryption. I was
| just trying to show that that is possible.
| lucb1e wrote:
| Not meant as critiques! And I did not assume it was using
| the Tor network, I understood the word "inspired" as you
| meant it. Clearly I need to work on my communication :(
| Valgrim wrote:
| One could build a service just around the fact that the
| fastest theorical time it takes to transmit information
| around earth is around 130ms. This means that the absolute
| maximum number of layers that could be used in a day is well
| below 1 million. Scale that over a few billion layers or
| more, and reveal a new key every roundtrip, and you would've
| got yourself a much simpler timelock encryption.
|
| The problem that arise is (and which is solved by the
| spacecraft to Neptune) is that with any earth based system,
| someone could secretly move copies of both ends closer
| together, secretly, and decrypt the lock faster than
| expected. Putting a spacecraft on a trajectory with no
| realistic chance of ever coming back makes this possibility
| impossible (as long as the layers of keys are encrypted only
| when the spacecraft arrived at its destination. Even if the
| delay between earth and neptune vary wildly, it is
| predictable, and any local system could piggyback a larger
| scale system like this for safety
| pjerem wrote:
| The spacecraft should generate the key pairs itself once it
| landed and send the public keys to earth to be sure no human
| stole the private keys.
|
| But, while fun, your idea is not that stupid.
|
| If the spacecraft continuously generate key pairs, you could
| even avoid landing it and "just" throw it in some direction,
| Voyager style (if you can afford rebuilding some every few
| decades) or on some orbit in the solar system. You don't have
| to pay for the landing tech.
|
| I wouldn't even be surprised that this could be viable
| economically. It doesn't sound that much technologically
| difficult
| troymc wrote:
| These are all good improvements. Thanks!
|
| My thinking now is that you could send the spacecraft out to
| Neptune and do a gravity-assist maneuver there, sending the
| spacecraft into a large orbit around the Sun, with a high
| perihelion.
| bigyikes wrote:
| >I wouldn't even be surprised that this could be viable
| economically.
|
| Do you imagine there's a large market for physically-based
| time locked encryption?
|
| Hard to imagine there's a ton of paying customers lol
| voxic11 wrote:
| Wouldn't landing a spacecraft next to the first one allow you
| to decrypt messages in essentially one round trip time? So if
| you had a message on earth timed locked for 100 years you could
| transmit it your your own spacecraft next to the decrypting
| spacecraft and it could almost immediately get through all
| layers of encryption and send you back the decrypted message.
| dave1010uk wrote:
| This is a really cool idea using fundamental properties of
| physics but I don't think it works.
|
| If the spacecraft is trusted by the person with the secret,
| it's much simpler to instruct the spacecraft to only disclose
| the secret after a set date. You don't seem to gain anything
| from the carded complexity.
|
| If the spacecraft isn't trusted, there's nothing it stopping it
| disclosing all the key pairs at once.
|
| I think the best bet at the moment is something like Rivest-
| Shamir-Wagner time lock puzzles, which requires a fixed number
| of sequential computations to perform.
| falsandtru wrote:
| Reading the cited Cloudflare blog, it seems that the main purpose
| of this technology is public randomness, and timelock is one of
| its applications. Since timelock is not the essence of this
| technology, it is not surprising that the usefulness of timelock
| is unclear.
|
| > it's become a reliable and production-ready core Internet
| service, relied upon by applications ranging from distributed
| file storage to online gaming to timestamped proofs to timelock
| encryption
|
| Details: https://drand.love/docs/timelock-encryption/
|
| Thread on the cited Cloudflare blog:
| https://news.ycombinator.com/item?id=39641475
| makach wrote:
| ..but will it stand the test against time?
|
| for robustness, the message should include the decrypt algorithm
| what about integrity and time travelers? i.e., can decrypt but
| just messing around with time
| Dibby053 wrote:
| What does this solve that couldn't be solved by simply disclosing
| the decryption key _oneself_ at the specified date?
| aarreedd wrote:
| https://drand.love/docs/timelock-encryption/#use-cases
| ghnws wrote:
| Death, for example
| tutfbhuf wrote:
| You can replace one or a few trusted third parties with an entire
| network of node operators (similar to the blockchain or Tor
| network) and achieve practical timelock encryption[^1]. As long
| as there are enough uncompromised nodes, you will be able to
| obtain your secret in the future.
|
| [^1]: https://github.com/drand/tlock
| tl988008 wrote:
| Actual timelock encryption, encrypted using parallel hashing and
| decrypted via forcing serial hashing:
| https://news.ycombinator.com/item?id=7848999
| mothepro wrote:
| There are solutions which don't require a third party. These
| would be guaranteed to survive in case a third party shuts down
| with a long duration.
|
| Paper: https://docs.google.com/document/d/e/2PACX-1vQe-
| OF0Lw9lutf6a...
| iskander wrote:
| Related: Verifiable Delay Function
|
| https://link.springer.com/article/10.1007/s00145-020-09364-x
| ttyprintk wrote:
| Chia ran a contest for those:
|
| https://news.ycombinator.com/item?id=18437659
| Swiffy0 wrote:
| On another note, I think something like this should come with
| some kind of zero knowledge proof of the future encrypted thing
| being what it is claimed to be, so that one doesn't have to wait
| for a long time just for the secret to encrypt into nothing.
| aarreedd wrote:
| That's a good point. Not sure how to do that right now
| jasonmorton wrote:
| You can ZK an XGBoost or neural net with
| https://github.com/zkonduit/ezkl
| victorbjorklund wrote:
| Very cool. Now I just need to find a reason to use it.
| bialpio wrote:
| This feels like Shamir's secret sharing with a pinky promise that
| "we won't decrypt things earlier", am I missing something?
| aarreedd wrote:
| Yes, essentially. However, the 'pinky-promisers' are large,
| well-funded, geographically distributed organizations that have
| strong incentives, both in terms of reputation and operations,
| to keep their promise
| neiman wrote:
| At first, I thought they used a cool new variation of something
| like VDF (Verifiable delay functions) or sequential proof of work
| to make a time lock.
|
| In these two options, you need to make a very long sequence of
| calculations to decrypt the message. Since the calculations
| cannot be parallized and since the sequence can be as long as you
| choose, it creates a time lock on the message.
|
| But no, they just use some kind of regular multi-sig/secret
| sharing.
| sterlind wrote:
| hrm. I was going to say it's extremely wasteful, but since it's
| sequential I guess you're only burning one core. There's no
| computational arms race like with blockchain PoW.
|
| How does the math work? The decryption key is some kind of
| exponentiation you can compute directly with a trapdoor, but
| without the trapdoor you have to repeatedly multiply instead?
| Uptrenda wrote:
| The problem with time-lock encryption is you need to design a
| scheme that remains secure for the entire duration you target. As
| you know: technology changes rapidly so that if your time-lock is
| far ahead in the future its hard to predict what technological
| developments might exist to break it.
|
| - If you use repeated hashing (or other measures of lengthy
| computation to derive a key) there's no guarantee that future
| computers won't be able to run your algorithm much faster than
| you did. A problem that will probably show up quite early with
| schemes of this nature.
|
| - If you use the threshold approach listed here. Can you
| guarantee that the machines providing the service are still
| available when you need decryption? Moreso: that they don't end
| up being hacked between the encryption and decryption time-frames
| through some 0-day.
|
| - You could use a hardware device to protect the keys. But this
| would mean that the devices weren't compromised by hardware
| attacks. We have seen Bitcoin wallets fall to hardware attacks
| and trusted computing environments like enclaves have numerous
| attacks that can be used to compromise their contents.
|
| What makes time-lock encryption so challenging is you need a
| scheme that is intentionally weak so that's it's broken after a
| certain point. In cryptography that level of specificity isn't
| needed because schemes are designed to be well and truly secure
| past the life-times of all the subjects who use them. Even
| greater than the life of planets.
| aarreedd wrote:
| FYI - this has used 33% of Cloudflare's daily free tier limit for
| workers since I posted this 3 hours ago.
|
| Every pageview and API call is an invocation. You get 100,000
| calls per day for free.
| klabb3 wrote:
| You can also send secret messages to future crypto analysts: just
| encrypt your message with a random key and throw it away.
| Guaranteed to be delayed until the chosen primitives are broken.
| TacticalCoder wrote:
| Rivest, Shamir and Wagner, 1996:
|
| _" Time-lock puzzles and timed release Crypto"_
|
| https://people.csail.mit.edu/rivest/pubs/RSW96.pdf
|
| FWIW it took me about 3.3 years of computation (on one core, it's
| not parallelizable), from about 2015/2016ish to 2019, to find the
| solution to Rivest' LCS35 problem (which he created in 1999, so I
| found the solution 20 years after he created that LCS35 puzzle):
|
| https://en.wikipedia.org/wiki/LCS35
|
| An article on WIRED for anyone interested (I'm still rocking the
| same monitor and same keyboard!):
|
| https://www.wired.com/story/a-programmer-solved-a-20-year-ol...
___________________________________________________________________
(page generated 2024-03-10 23:00 UTC)