Topic: Time-release encryption using Bitcoin? (Read 1604 times)

What are the applications for this and how much value would it have in the market?

It is already possible to require the production of  X  such that SHA256(X) == Y is a check for spending.

So you can can use an Error Correcting Code to create 10 chunks such that any 5 of the 10 chunks can be used to reassemble the entire key.    Then create a transaction that generates outputs spendable when X is provided and after a certain number of blocks have passed.   

Then broadcast  chunks 0 to 10 to a whole host of random people with instructions on how to claim the money.   

Once 5 people claim the money the private key is revealed and the data can be decoded.

No one would reveal X before the transaction could be spent because only the first one to claim it gets it. 

Note by "key" I don't mean Bitcoin keys.

I meant the key holders wouldn't be able to find other key holders until they reveal their portion of the key in the blockchain, then anyone who is looking for the key would be able to find it in the blockchain.

I imagine there's some cryptographic solution to that particular problem, I just haven't thought it through completely.

What prevents the keyholders from watching the bock-chain?

The Bitcoin protocol relies on people being able to prove they have a key without actually revealing that key.

Very interesting idea!  Watching this thread.

Snowden's (and previously Wikileaks') use of encrypted "insurance" files got me thinking: how could we leverage the blockchain to implement time-release encryption? That is, the encryption keys to decrypt a certain file are released after a certain time (either the full key is released publicly, or it can be combined with a private portion of the key)

Bitcoin's "nLockTime" seems like the obvious place to start. Here's a rough sketch of the scheme I've been thinking of:

The main primitive is transactions including some "bounty" that can only be spent after a specified time (nTimeLock), if a piece of data (the key) hashes to a specific hash. The output address can be chose by the person redeeming it. (sorry, I don't know all the correct terminology)

Your encrypted file uses an n-of-m scheme, so it can only be decrypted if at least n of the m keys are known.

You pick m different people to hold the keys ("key holders"), and give each one a transaction in the blockchain they can redeem after the specified time if they include their key in the transaction. As long as n of the people redeem their transactions the file can be decrypted.

If the key holders collude to combine their keys (off chain) beforehand then they would risk the other key holders claiming their bounty.

The problem is if they determine the decrypted information is worth more than the bounty. Perhaps a surety bond scheme could be layer on?

But ideally the key holders wouldn't even be able to find the other key holders without revealing their keys, and they wouldn't know which encrypted data the keys they're holding unlocks (while still allowing someone watching the blockchain to figure it out)

Note this scheme doesn't support revoking the keys. If you could somehow invalidate the transactions then the key holders wouldn't have any incentive to not collude.

I'm sure there are improvements that could be made. I'm interested to hear other ideas.