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

Timelock.dev / drand-based approach

• Service uses a distributed set of organizations (“League of Entropy”) running nodes with threshold cryptography: a subset must cooperate to release secrets at specified rounds.
• It repurposes an existing public randomness / threshold-signature system (drand); timelock is one application rather than the core design goal.
• Values after initialization are deterministic; initial randomness sources (e.g., lava lamps) only seed the system.

Trust, decentralization, and incentives

• Multiple comments note this is not trustless: users must trust many organizations not to collude, leak keys early, or go offline.
• If the network disbands, operators plan to delete keys, making recent ciphertexts permanently undecryptable; this is framed as a privacy vs availability tradeoff.
• Some argue there is no fully decentralized algorithmic timelock today; others disagree but provide no concrete alternative beyond suggesting publication in crypto venues.
• Ideas involving financial incentives (bonds, penalties, whistleblowers) are discussed, but concerns are raised about bribery, coordination, and shifting trust to whistleblowers.

Alternative timelock mechanisms

• Classical time-lock methods are discussed:
  • “Break in the future” via RSA/ECC or weak crypto, relying on future advances in computing or quantum.
  • Rivest–Shamir–Wagner time-lock puzzles: sequential modular squaring, believed non-parallelizable, with real-world examples taking years on a single core.
  • Hash-chain approaches and verifiable delay functions (VDFs), where decryption requires a fixed amount of sequential work; criticized because specialized hardware can massively speed them up.
• Ethereum/smart-contract and HTLC-style approaches are considered poor fits: they can enforce timing of transactions but cannot hide data from validators.

Physics and physical timelock proposals

• Several thought experiments use physical constraints:
  • Spacecraft carrying private keys placed far away (e.g., Neptune orbit or solar escape) so speed-of-light latency enforces a lower bound on decryption time.
  • Simpler analogues include shipping containers, buried keys, dangerous locations, and “geocache” style puzzles.
• These are acknowledged as theoretically interesting but economically dubious and still dependent on trusting hardware and procedures.

Use cases and open problems

• Suggested uses include posthumous messages, dead-person switches, digital self-control (locking oneself out of accounts), and DeFi mechanisms.
• Skeptics question why not just self-release a key later, or use simpler intermediaries (e.g., a notary).
• Several comments emphasize a deeper unsolved problem: securely and trustlessly agreeing on elapsed time, given that all current schemes rely on either trusted parties or assumptions about future computation.