2

An example _callback function from Oraclize:

function __callback(bytes32 _queryId, string _result, bytes _proof)
{
    if (msg.sender != oraclize_cbAddress()) throw;

    if (oraclize_randomDS_proofVerify__returnCode(_queryId, _result, _proof) != 0) {
        // the proof verification has failed, do stuff

    } else {
        // the proof verification has passed, do stuff
        uint random = uint(sha3(_result));
        myNumber++;
    }
}

Is it possible that Oraclize could call this function twice for one query ID such that myNumber increases twice? I get it would cost money them to do so, but if they do control the execution of this function I might add a boolean modifier for integrity of those numbers.

1

If there is nothing within the contract, stopping Oraclize from repeat-calling a callback function with the same queryId, then you should assume it is possible, and make appropriate arrangements to prevent it. This is already done by existing contracts in varying ways, such as tracking in storage, whether a certain queryId, has been processed.

The above is theoretical, and mentions a theoretical yes, regarding Oraclize's capability of calling as much as it wants without an appropriate contract check. In practice, this can and does occur with Oraclize, but not out of maliciousness, instead it may repeat a broadcast due to a change in the network, which either made the previous transaction disappear, be re-organized or appear invalid and to try and ensure it is sent to the network for assurance of quality-of-service it may result in repeats. If repeats trigger an unwanted circumstance, then you will need to track whether a certain query Id was processed.

  • That is definitely reasonable and makes sense, also a good non-malicious reason why it could happen. It's just good to know the gotchas that could break things... But you don't know of any mapping they keep of successful callbacks, on chain, to specifically prevent that? I personally can't find anything but if I don't have to duplicate a check on a crucial callback that costs gas I'd rather not. – Duncan Brain Feb 8 at 19:53
  • So just out of disclosure, I am with Oraclize :). Oraclize itself doesn't keep any mappings, the callbacks comes directly to your contract from an EOA (Externally-owned-account e.g. not a contract). To keep a mapping itself, it would have to first proxy through some contract on-chain, and then forward to target contract, which would needlessly put the expense on all contracts, when not all contracts are necessarily adversely affected by a repeat call. – DenisM Feb 9 at 0:28
  • Haha I know, I think we have chatted before! Obviously I think the tool that your team is working on is really useful so thank you! In terms of finishing off this question though, there are a lot of 'theoretical's' in your answer that make it hard to be sure. If you combine your last comment with the original answer I can call this case closed on my part! Basically: "It's possible, possible reasons it could happen, there is no on chain check for previous callbacks, and suggestion to account for that in callback with some form of check if it affects the contract state. – Duncan Brain Feb 10 at 15:10

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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