Live data from Hacker News

Show HN: Timelock.dev – Send a secret into the future using timelock encryption

timelock.dev

71–80 of 149 posts

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#71
post #70

Earlier quoted context omitted.

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 int…

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)

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#72
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.

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#73

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

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.

This is not true at all.

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#74
post #17

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 en…

[deleted]

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#76
post #64

This feels like Shamir's secret sharing with a pinky promise that "we won't decrypt things earlier", am I missing something?

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

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#77

Earlier 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.

This is not true at all.

Would love to know how

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#78
post #5

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,…

It's also tough to find good algorithms where you can't just spend double to half the time until it unlocks.

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.

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#79
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.

Re: Show HN: Timelock.dev – Send a secret into the future using timelock encryption

#80
post #70

Earlier quoted context omitted.

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 int…

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.
Post reply on HN