Quote from: digaran on December 15, 2023, 03:35:08 AM

@OP, by any chance, are you trying to build a security related network? Maybe if the exact time is not an issue, you could send a dust transaction and have the time of confirmation as your proof of being on the right chain? So you'd have to pay the fee for using Bitcoin's network as a safety measure.

Yeah, in some way, but no network involved. I'll start from the beginning. My goal is to code a time capsule. The program should work as follows.

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 this 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): give the program the whole 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?

PD: should I mark this topic as solved and post the time-capsule-related question as a new one? Whatever gathers more attention.