Post
Topic
Board Development & Technical Discussion
Merits 11 from 6 users
Topic OP
Using Bitcoin as a time capsule?
by
ltcltcltc
on 16/12/2023, 19:07:00 UTC
⭐ Merited by EFS (4) ,PrivacyG (2) ,ETFbitcoin (2) ,garlonicon (1) ,vjudeu (1) ,DdmrDdmr (1)
Some days ago I asked for help with the building of a trusted clock using BTC. I got a few replies that helped a lot and led me to a solution to the problem. But my true goal is to code a program that acts like a time capsule. Its task is to safely encrypt data during a set period of time and decrypt it afterwards. Here it is in a more detailed form.

  • Input (at t=now): release_date (UNIX time value), encrypt=True (bool).
  • Output (at t=now): encrypt_key (type key).
  • Input (at t≥release_date): encrypt_key (type key), encrypt=False (bool).
  • Output (at t≥release_date): decrypt_key (type key).

Take some data you want to send to the future. Give the program a release date, encrypt your data with encrypt_key and throw the raw data and the encryption key away. Safely store the encrypted data. Wait. After the specified date, give the program back its encrypt_key and get back your decrypt_key to decrypt your data with.

Everything must be run locally.

Critical assumption: the user is good-intentioned right until they throw away the raw data, after which they feel an immense regret and become malicious.

The problem: make it as hard as possible to get decrypt_key before release_date

First idea (which led to the previous post): 1) make the program get the current date from a trusted source and compare it to release_date; 2) if time is up proceed to outputting decrypt_key.

This can be beautifully solved by BTC (or any other PoW-based cryptocurrency, really): after release_date, give the program the longest chain of block headers; the program will check the PoW, that the difficulty increase is coherent and that the time intervals are not suspicious (i.e. 10 mins on average, also if the last time interval is 2 days, it might suggest that a malicious user mined their own last block and faked the timestamp... a few details should be taken into account despite compromising accuracy). The beauty for me is that the program doesn't care if the chain is the longest or whether it's been confirmed by the network: it only wants the proof of work; and the good-intentioned user doesn't need to bother about calculating that PoW: miners do that for them!

This already makes for long-term reliable (though potentially very rough) time-checking method, but my task is to build a time capsule. I still face the issue of having to obfuscate the code responsible for producing decrypt_key. Sadly there is no way to avoid the threat of reverse engineering, especially for locally run programs. If a machine can follow the instructions in your executable, so can a talented enough human.

Second idea (here you BTC geeks might help out): using the lock_time parameter. The program can issue a transaction that's time-locked to release_date. How could I exploit this feature? Or to put it another way: what kind of information does the user gain when a transaction is processed by the network?