1

I see that there are no parallel execution in EVM. The problem I am trying to solve is the following: I have a contract which takes the input of two parties -- say users A and B. The result of the contract depends on both inputs, but if A calls the contract first, then I would this input to not be public until B calls the contract as well. The point is, both parties should not know each other's input before both have called the contract. Imagine a card game, where both players have to choose a card simultaneously and put them on the table face down, to be revealed at the same time.

Is this possible?

| improve this question | |
0

As you can't hide information in the blockchain you have to use other means.

If you are familiar with how the mining process works we can use the same logic here. The whole point of the mining (mathematically speaking) is that the actual mining is hard but verifying the results is trivial. So once a miner successfully mines a block he publishes the nonce used to mine the block - everyone else can just trivially check that the nonce is the correct one.

So in your case you can ask the participants to hash their inputs and submit the hash values. As it's impossible to get the input from the hash value the data is safe. When both have submitted their hash values they state their actual inputs and both parties can easily verify that the input results in the correct hash.

Depending on your input structure you probably also want to include some sort of salt value. For example if the input is simply a number between 1 and 10 it's easy for the other party to bruteforce all the 10 hash values to see which is the correct input and abuse that information. But if you include also some salt value it becomes unfeasible for the other party to try to bruteforce the input.

Here's some more info on salt: https://en.wikipedia.org/wiki/Salt_(cryptography)

| improve this answer | |
  • Thank you! I thought about hashing the input but the problem is what you said, it is a very small set of possibilities. The salt thing is probably what I was looking for. Edit: However, now that I think about, the salt has to be publicly known, right? In this case the "cheater" could just try all inputs (which are just 13 different values) combined with the salt and bruteforce it... – Xito Dev Nov 4 '19 at 9:09
  • Okay, one way is to use another transaction. They both send their salted hashed inputs. Once they are both in, the users can send their "salt". Curious to know if there is a "cheaper" way (here we use a total of 6 transactions: both users sign in to the contract -- i.e. agree to play, both users send their inputs, then both users send their salt). – Xito Dev Nov 4 '19 at 9:20
  • No the salt doesn't need to be publicly known. The participants can just reveal the salt when they reveal their input. – Lauri Peltonen Nov 4 '19 at 10:01
  • If the salt is not publicly known then it opens the possibility that when they have to reveal their input&salt they just find another salt which produces the right hash with another input - but that's a lot of computations and most likely not a concern. – Lauri Peltonen Nov 4 '19 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.