Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Random datasource example allows ransoming winning players #29

Open
gorgos opened this issue Oct 12, 2018 · 3 comments
Open

Random datasource example allows ransoming winning players #29

gorgos opened this issue Oct 12, 2018 · 3 comments

Comments

@gorgos
Copy link

gorgos commented Oct 12, 2018

Given the restriction to submit query results only for Oraclize in the exemplary implementation:

https://github.com/oraclize/ethereum-examples/blob/e7f364bb104f0b79eeb1eaec9fb4b7bb316d1cd5/solidity/random-datasource/randomExample.sol#L26

the described ransoming mechanism in the paper is possible. Simple solution would be to remove that line. To quote the paper

Since only valid result will be executed, there is no need to limit the access only to the data carrier.

@D-Nice
Copy link
Contributor

D-Nice commented Oct 18, 2018

We'll have a look into this, in general, users are free to of course to implement it that way. You are right that regardless of who the sender is, it would have to be someone with access to the matching session keys, so it is a bit of a redundant check, but its removal would still not stop Oraclize from committing DoS or potentially ransoming winning players.

From my perspective, Oraclize is a data carrier, and as is, you do have to trust it to pipe data along to you, but the various proof mechanisms surrounding it are in place so there's not trustline between Oraclize and the contents of the data itself(assumg you're using a proof and having it checked), just the provision of said data.

I will ping @bertani into this discussion to have a look as well, and please feel free to share further feedback or ideas if you have it.

@gorgos
Copy link
Author

gorgos commented Oct 20, 2018

its removal would still not stop Oraclize from committing DoS or potentially ransoming winning players

It would not stop Oraclize from DoS, you are right about that. But it would stop them from ransoming winning players. To quote the paper again:

This makes the authenticity proof fully transferable and the data carrier would have no way of ransoming the winning player without the facto publishing the proof.

In other words, if Oraclize wants the winning player to believe them that he has won, Oraclize would have to prove that to him by showing the random result along with the proof. The winning player could then simply submit the data to the smart contract himself.

@D-Nice
Copy link
Contributor

D-Nice commented Oct 24, 2018

What you're mentioning is technically already achievable, if a user uses our check query tool: http://app.oraclize.it/home/check_query (they can enter their bet transaction id which spawned an Oraclize request)

They are able to see the query being processed, and if Oraclize is not committing DoS, the random result and proof bytes would be shown there, or via the raw API link at the bottom. So this is in fact an implementation that a dapp developer can follow if they so wish, however, it can be considered cumbersome for end-users as they have to provide the callback themselves, and it's not a method Oraclize officially support, however, it's undoubtedly a good fallback to add I'd say still, assuming you've audited what removal of the oraclize cb address check entails for your contract.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants