Time lock cryptography is an old problem apparently originally described by Tim May, I had no idea. A solution to this was described at https://people.csail.mit.edu/rivest/pubs/RSW96.pdf long ago. Basically, a ciphertext is constructed such that it takes n operations of squaring a number (modulo) to recover it, So, a time lock blockchain might perform these squaring operations as proof of work, to mine its currency. Demand would be produced by people paying to encode time lock messages. Each block would announce decrypted messages. To keep the mining effective, as the time lock protocl and the security of the chain depend on the network being the strongest source of computation that exists, it could be important to make it very clear to miners how to improve the mining algorithm and tune it for new hardware. Rather than hiding it away in mining apps, a good focus might be on figuring out what parts can be factored into user control, and how to ease users writing their own GPU kernels, FPGA layouts, etc, with minimal training. It's obvious that this solution is obvious. However, it is not mentioned at https://crypto.stackexchange.com/questions/606/time-capsule-cryptography in my "internet", and the site gives me errors when I try to log in to post. First steps might include cloning code for an existing blockchain, and coding the Rivest algorithm into the mining and verification code. A websearch shows some of the existing attempts: - drand has timelock cryptography https://drand.love/docs/timelock-encryption but it fails if nodes are compromised since they hold the private material in a multiparty manner, whereas Rivest's solution does not have this failure uhhhhhhhhhhhhhh I ran into https://eprint.iacr.org/2023/189.pdf which mentions a number of other approaches to this, _none_ of which were mentioned on stack exchange ?? this is apparently an old and popular problem for 30 years. thinking the stack exchange is broken and others aren't logging in either or something. there are apparently a number of existing solutions to this, but it is not immediately obvious what their security guarantees are.
the LCS time-lock puzzle released in 1999 by Ron Rivest was anticipated to remain secure for 35 years, but was successfully solved fifteen years early in 2019 via two independent methods [csa19]: once by simply running sequential operations on a single core of a modern CPU for 3.5 years, and again by running the computation for only 2 months on dedicated FPGA hardware. Rabin and Thorpe take the alternative approach and propose the idea of relying on Pedersen distributed key generation, Feldman verifiable threshold secret sharing, and ElGamal encryption [RT06]. Therein multiple parties implement a “Time-Lapse Cryptography Service” by publishing public keys and then releasing the related private keys at given times. To the best of our knowledge such a Time-Lapse Cryptography Service has never been implemented and deployed in practice. Moreover this setting requires explicit action by a threshold of members to compute the decryption operation. In other words, the work required by the network is linear in the number of ciphertexts to decrypt. In [LJKW18] a timelock scheme is built on top of the concept of computational reference clocks using extractable Witness encryption, and a practical instantiation relying on Bitcoin is presented. However, this scheme relies on multilinear maps which have not yet been securely constructed. In [CDK+21] IBE and Witness encryption are again used to achieve a novel notion of “Encryption to the Current Winner” (ECW) where the receiver of an encrypted message is determined by the current state of a blockchain and is not yet known at the time of encryption. Ultimately this scheme is then transformed to achieve a different notion of “Encryption to the Future” (EtF) towards parties selected at arbitrary points in the future, unlike classical timelock or Timelapse encryption where any party knowing the ciphertext can decrypt once the specified time has passed. In direct contrast to our timelock definition which permits anyone to decrypt after the designated time, in EtF only some party with certain rights (the future winner) not yet determined in the present can decrypt ciphertexts. Notice that the setting is also quite different between both works, assuming dynamic committees with the strong assumption that “YOSO”—You Only Speak Once. This has not yet been implemented nor deployed in practice to the extent of our knowledge. Threshold networks have also been used as an encryption “recipient.” For example, Ferveo [Ano21] and Shutter [shu22] are systems where users encrypt their transactions for threshold networks (which can also be the validator set of a blockchain). Once encrypted transactions are included in a block, they get decrypted by the network, thereby preventing front-running. In comparison, our scheme does not rely on the threshold network to perform an operation per ciphertext, rather simply to emit one value per round and the decryption happens publicly. Anyone can compute a valid decryption of a ciphertext encrypted for this round.