Random datasource example allows ransoming winning players

[gorgos]

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]

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]

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]

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.