Should fee estimation in transactions going trough accounts require a valid signature?

[ericnordelo]

Currently, fee estimation requires a valid signature, because the account contract itself will revert if not received (even with the transaction query version).

This could be a UX issue for example for hardware wallets when the user would need to sign two messages to send a transaction: one for fee estimation (with max_fee equal to 0), and a different one for execution (with the actual max_fee).

A potential solution for this could be to bypass the signature for transactions with an id greater than the query version offset.

[yoga-braavos]

Note that when using other curves, namely secp256r1 for mobile-based hardware signing, the signature verification itself uses a considerable amount of gas. Just dropping signature verification will reduce the fee estimation and not reflect to the user the actual fee when using hardware signer.

[ericnordelo]

Great point. What about keeping the verification step, using a signature from a "public" private key (instead of the user one) for transactions with an id greater than the query version offset (This could be standardized for estimators)? Could the fee estimation be significantly different with different valid signatures?

[theyoga]

Great point. What about keeping the verification step, using a signature from a "public" private key (instead of the user one) for transactions with an id greater than the query version offset (This could be standardized for estimators)? Could the fee estimation be significantly different with different valid signatures?

Indeed that's what we're doing in Braavos's mobile app. We allow a "dummy" secp256r1 signature to pass when txn version is estimate fee version. We also confirmed with Starkware (and checked ourselves) that regular invoke-s cannot be sent with this transaction version:

    // 1. Allow fee estimation using seed for better UX on app side (no bio pop-up)
    let (tx_info) = get_tx_info();
    if (tx_info.version == TX_VERSION_1_EST_FEE) {
            _dummy_secp256r1_signing_for_gas_fee();
            return ();
    }

_dummy_secp256r1_signing_for_gas_fee() is just a "dummy" hard-coded pub-key, hash and signature that we took from our tests.

Note that another possibility is to just return without any dummy signing, but then client-side have to maintain the number of steps for signature verification and change it when implementation changes

[ericnordelo]

Awesome. I think probably is worth defining and adding something like this to the OZ accounts @andrew-fleming @frangio @martriay.

[frangio]

This seems like something that should be part of the Account standard.

[ArielElp]

In 0.11.0 we'll add a skip validation option to estimate fee. It's up to the wallet to handle the account for validate itself. If you think it's negligible or has a simple approximation (e.g. offset by some constant), you don't have to bother going through the signing flow.