8

I know about the general open / trustless protocol of storing transactions. How would I approach a scenario here where I want to store some data in a contract on deployment, to later be retrieved by someone unknown at the time of deployment?

The main problem here is that the receiver of the secret data is not known in advance / when providing the secret data. Therefore simply encrypting the data with buyers public key is not a valid approach

E.g. I have a contract which stores secret number and other users can interact with the Dapp and bid on these numbers, only the highest bidder shall receive the true secret number in the end.

Improve this question
5
  • 1
    EDIT: Different but related question ethereum.stackexchange.com/questions/2624/…
    – eth ♦
    Commented Mar 29, 2017 at 10:10
  • It is partially answered by the linked question, although the linked question assumes that you know the receiver beforehand, which is not the case in this scenario. Shall I clarify and reopen, or add a comment to the other question?
    – floAr
    Commented Mar 29, 2017 at 10:22
  • I think with the clarification this is a sufficiently different question.
    – Tjaden Hess
    Commented Mar 29, 2017 at 18:47
  • Also, does the contract have to do this all on its own, or can the deployer just encrypt the number with the bidder's public key after the bidding is over?
    – Tjaden Hess
    Commented Mar 29, 2017 at 18:53
  • This is of course a possible solution, but I would love to have everything as autonomous as possible. If the dev encrypts the value afterwards the buyer needs to trust the dev. Having the contract holding the data from the beginning would allow the whole thing to be trustless, basically removing the possibility of the dev taking all the ether and not giving out the data
    – floAr
    Commented Mar 30, 2017 at 9:01

1 Answer 1

Reset to default
3

There is no complete way of doing this. One approach you could look at is:

You could commit to the secret in advance (by having the contract hold a hash of the secret). When you know the recipient you could send them the secret encrypted with their public key, which they can then decrypt and check matches the earlier committed hash. Nothing forces you to do this, but at least you can't change your mind on what the secret was after the fact. NB - nothing forces you to actually reveal the secret though.

You could come up with a variation on the above involving one or both parties putting up stakes that are only refunded on a successful outcome / conclusion, but this wouldn't solve the underlying problem entirely.

There are some research / development efforts going on in this area (including homomorphic encryption) and Hawk) but nothing that seems even close to being ready for primetime.

My view is that these types of functionality will be part of web 4.0 ;-)

Hope this helps!

Improve this answer

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