Ethereum is a forthcoming cryptocurrency. Like Bitcoin, it relies on a blockchain to generate distributed consensus about transactions and account values. What makes Ethereum different is that accounts are more than a keypair and a balance: Every ethereum account is a program which can autonomously store, manipulate, and send money or other data within the Ethereum network. For example, I could create an account that gifts 100 ether to anyone who sends a message containing the string “Jai is great” to the account (until the account runs out of money). If I really wanted, I could make this account autonomous and unchangable, so I couldn’t change it later even if I wanted to.
More practical example:
Alice wants to publish an encrypted message that can only be read after a certain date (the “embargo”). Maybe she wants to prove she predicted something in advance, or maybe she has a secret she wants told in the future. She creates a contract which contains a weakly-encrypted message – breakable, but only with a serious effort. The contract pays out a reward $R when someone submits the plaintext of the encrypted message, but only after the embargo ends.
A lot of the problems with this plan are the constraints $R has to fit:
- Alice has to spend $R to set the whole scheme in motion
- $R has to be more than the cost of decrypting the message ($D) at the decryption date
- If anyone thinks the value of the secret ($S) is worth more than $D before the decryption date, the jig is up.
- $D will change over time as advances in algorithms and hardware make decryption cheaper. This can be difficult to predict.
In short: This might work if $R>$D>$S holds for every point in time from encryption to decryption. The bigger $R is, the better Alice’s chances of everything working out the way she wants (bigger $R -> more motivated future decryptors -> stronger encryption -> higher cost of pre-embargo decryption).
A semi-trustworthy third party could make this cheaper, assuming it’s a semi-popular service. A Keymaker, K, publishes decryption contracts that correspond to every day in the next 20 years. Contract 1 pays out after tomorrow; contract 2 pays out in 2 days, etc. The content of each contract is just an encrypted private key. K also keeps all the public keys secret. If you have a secret you’d like to release on day n, you can pay K a certain amount and she’ll give you the public key for contract n. You encrypt your secret and make the ciphertext public, announcing that it will become readable when the corresponding K contract unlocks and the private key is revealed. You don’t even have to announce which day the unlock is – so no one except you and K will know how long you’re planning to keep your secret.
Problems in this new scheme:
- K has access to all the private keys and can read all the secrets whenever she feels like it. An ethical/reputable K would generate all the private keys at once, encrypt them, upload the contracts, and delete the private keys immediately – before taking on a single customer. This is feasible, but there’s no way for customers to verify that K did that.
- Once a customer gets the public key for day n, they can share it with all their friends, or even publish it publicly, creating a free-rider problem that wrecks K’s business model.
You could mitigate these problems with multiples key providers (K1, K2, K3). Alice encrypts her message n times.
I’m trying to think of other ways for people to cooperate on time-locking secrets, or how to line up incentives for high-frequency embargo contracts, or how to tune the difficulty of decryption after the fact (obviously you can only reduce the difficulty, but how granular can you make that reduction?) That could allow for overestimation of the initial key difficulty, with K scaling back the difficulty to accomodate technological progress (while still setting an upper limit on difficulty if K suddenly disappears for some reason).