I'm looking for a way for my contract to release a secret once some condition has been met (e.g. someone provided the right input). The question is where the secret could be stored in the meantime. Obviously the contract and its storage are public. And encrypting the data only moves the issue to storing the private key somewhere only the contract could access. Anyone here that has solved this chicken-egg-like problem?
0 ·
Comments
IBM appear to be working on it, though again there is no research to prove it is entirely resistant to attack.
Sorry if that wasn't completely clear, but what I also wanted to know is whether it is possible for a contract to store something out of reach for others? A locker only the contract can open. Of course preferably without using trusted third parties.
H(S)
and later reveal it. If none of them is suitable, maybe you can create a 'servicer' party that can do it - if you can figure out a way to not give that third power too much power.Really depends on what the problem is. Assuming the servicer party is not also a user, a big assumption. In that case you can have the servicer put in stake, anyone that can guess the secret earns the stake. So if the servicer where to reveal the secret to the user, the user might also steal the stake.
Might work better if the stake is something only valuable to the servicer. I.e. Ethereum has the name "ethereum" in the name registry. Losing the stake could be a more towards losing the name.(cant really risk losing the name immediately.)
Suppose you make a obfuscated code contract that sends 1 BTC in exchange for a transaction with 2000 ETH sent to it. Let's even say that the obfuscation is so good that an attacker can never retrieve the original code. Problem solved? Nope.
The attacker can simply copy the contract to a private blockchain and run the contract's copy with imaginary ETH. The output of the copy, however, is a bitcoin transaction just as valid as if it was from the original, and the attacker can broadcast it on the real network.
To avoid this, we must use a third party to hold some additional secret, without which the obfuscated program does not work. At which point we end up with a third party anyway, and it is just simpler to run an unobfuscated contract which requires said third party's permission.
Perhaps you mean Bitcoin funds.. No idea how to actually control bitcoin funds while using information available in transactions/bitcoin blockchain. Not by doing less-than-SPV-in-Ethereum, but that seems.. involved. And you might need to deal with hard forks affecting SPV. (latter can be done though) "Splitting a key" is probably best achieved with multisig, and basically different parties escrowing/voting for things.