Improve how to estimate what to pay for Oracle requests/callbacks

[gsmachado]

Summary or problem description

Imagine that you have a smart contract with two methods:

public class CallOracleContract {

    ...

    public static final StdLib stdLib = new StdLib();
    public static final OracleContract oracle = new OracleContract();

    public static void request(String url, String filter, int gasForResponse) {
        oracle.request(url, filter, "callback", null, gasForResponse);
    }

    public static void callback(String url, Object userData, int responseCode, ByteString response) throws Exception {
        if (Runtime.getCallingScriptHash() != oracle.getHash()) {
            throw new Exception("No authorization");
        }
        ByteString serialized = stdLib.serialize(new CustomResponseStruct(url, responseCode, response));
        Storage.put(ctx, responseKey, serialized);
    }

    ...

}

Before calling the request method, how can I estimate how much GAS the callback cost that I can accurately specify to the request method (more specifically, the gasForResponse param)?

It's not possible to call invokescript or other methods because the first line of callback uses Runtime.getCallingScriptHash(), even if the developer knows what the response will look like (i.e., the size of it).

Do you have any solution you want to propose?

Instead of providing an accurate way to estimate how much GAS the callback would cost, a better solution would be to issue a "refund" back to those who requested the Oracle call. For example, if a higher amount was specified on the gasForResponse param, then the remainder will be refunded.

FYI: @shargon @Jim8y @superboyiii @mialbu

[shargon]

I vote for refund

[lock9]

Refund or slippage. I remember that there was some issue with refunds. Was it a security problem? I can't recall it

[shargon]

Refund or slippage. I remember that there was some issue with refunds. Was it a security problem? I can't recall it

If the oracle sign more data to waste the gas, you will lose all of them

[roman-khimov]

Duplicates #1982 (I'd close this one because of that).

Related to #2806. But still requires an additional mechanism since it's an additional transaction executed in its own context.

[shargon]

Duplicates #1982 (I'd close it because of that).

Related to #2806. But still requires an additional mechanism since it's an additional transaction executed in its own context.

I like to see that my opinion was the same hahah #1982 (comment)

[vncoelho]

Good, refund is a good feature and solution.

[roman-khimov]

In the game of duplicates, older ones win to me, let's move this discussion into #1982.