Can a contract keep a secret?

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?

Comments

  • GeorgeHallamGeorgeHallam Member, Administrator, Moderator Posts: 229 admin
    So, homomorphic encryption will solve the problem, unfortunately in practice its very difficult to implement and as far as I'm aware not fully solved yet.

    IBM appear to be working on it, though again there is no research to prove it is entirely resistant to attack.
  • cybercocyberco Member Posts: 20
    Yes, that would solve keeping it secret but it's still a long way before it will become practical.

    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.
  • GeorgeHallamGeorgeHallam Member, Administrator, Moderator Posts: 229 admin
    On a public blockchain, it is impossible to store something which would not be viewable by others. In respect to this it may we worth looking at off-chain solutions.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    You can have non-contract participants commit a secret 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.)
  • SmithgiftSmithgift Member Posts: 64

    So, homomorphic encryption will solve the problem, unfortunately in practice its very difficult to implement and as far as I'm aware not fully solved yet.

    That won't help with this kind of thing, unfortunately.

    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.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Smithgift said:

    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.

    Well, the interaction with the third could be such as to not give that third party much room. For instance not-relinquishing the secret can also put a deposit/stake at risk. As implied, figuring out how to make it work does complicate, but if you cant find a solution otherwise...
  • eaglgenes101eaglgenes101 Member Posts: 43
    reignbeau said:

    OMG. This exact question has been plaguing my brain for a week. The contact needs a private key to send funds, if the private key is on the contract then everyone can read it.

    The solution is entrust a piece of the key to different people, so they would all need to collude to be able to spill beans.
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @reignbeau @eaglgenes101 At least, within Ethereum, contracts do not operate with pubkey crypto, what they do is totally a logical consequence of messages they receive. The messages, potentially with funds, sent as result is totally up the the contract execution. Not knowing that is basically not understanding Ethereum.

    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.
  • drinkcoffee2016drinkcoffee2016 Member Posts: 5
    edited July 2016
    @cyberco you could have users register their public keys with your contract, and then encrypt data using ECIES based on that public key, and put the encrypted data into the contract for the user's later retrieval. You would want to ensure that your contract checks that the public key corresponds to the user's account.
Sign In or Register to comment.