Related: Verifiable Delay Function https://link.springer.com/article/10.1007/s00145-020-09364-x
Chia ran a contest for those:
Show HN: Timelock.dev – Send a secret into the future using timelock encryption
61–70 of 149 posts
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#62On 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.
That's a good point. Not sure how to do that right now
You can ZK an XGBoost or neural net with https://github.com/zkonduit/ezkl
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#63Very cool. Now I just need to find a reason to use it.
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#64This feels like Shamir's secret sharing with a pinky promise that "we won't decrypt things earlier", am I missing something?
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#65Earlier quoted context omitted.
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.
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…
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.
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#66Earlier quoted context omitted.
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…
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'…
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.
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#67The 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,…
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?
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.
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#68[deleted]
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#69Here'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 en…
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. Y…
>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
Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption
#70Earlier quoted context omitted.
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?
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…
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?