3

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.

Improve this question

2 Answers 2

Reset to default
2

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.

Improve this answer
3
  • 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, 2019 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, 2019 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, 2019 at 15:10
1

From talking with DenisM the answer is yes, it could be called twice -- and you should prevent it if a second interaction with your contract would cause problems.

It could happen for example if Oraclize repeats a broadcast due to a change in the network or to ensure quality of service.

Thanks DenisM for your help.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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