Default priority has no mapping in get_fee_estimate

[woodser]

Currently there is no mapping from default transaction priority to the fee estimates provided by get_fee_estimate.

This prevents third parties from verifying that a transaction was generated with default priority. The best they can do is verify that a transaction was generated with uimportant priority.

This issue requests providing a such a mapping.

One way it could be done is by adding a new RPC call to monero-wallet-rpc. For example, get_default_fee_priority(), which returns 0-3, corresponding to unimportant, normal, elevated, and extra elevated.

Alternatively, the daemon could calculate and provide the mapping, but this would be a bigger change.

[iamamyth]

I'm a bit confused as to who these "third parties" would be, as anyone relying on get_fee_estimate could easily be fooled by the new endpoint, too, as they'd don't have a "trusted" daemon. Or, if someone trusts the daemon, but not the client connecting to it, they can't ever confirm the client used the right daemon. Who does this help?

[iamamyth]

Is the goal here to just help the client pick the right fee? If so, I'm not sure why you wouldn't add a field to the existing response, except, I suppose, the priorities and the default may have different change frequencies, but I suspect most clients will just call the endpoints in a pair, so splitting them makes net more work for the daemon.

[woodser]

I'm a bit confused as to who these "third parties" would be, as anyone relying on get_fee_estimate could easily be fooled by the new endpoint, too, as they'd don't have a "trusted" daemon. Or, if someone trusts the daemon, but not the client connecting to it, they can't ever confirm the client used the right daemon. Who does this help?

In our use case, peers submit signed transactions to an arbitrator for verification. For example, peers submit a "penalty" transaction which the arbitrator may broadcast if they misbehave during trade initialization. They also submit signed transactions to move funds to a shared multisig wallet.

The goal is for the arbitrator to verify that the peers used an appropriate mining fee at current congestion levels, to ensure protocol reliability.

Therefore, peers should use the "default" fee priority, to adjust to current congestion levels, and the arbitrator needs to be able to verify that the fee meets the current default level as well.

The problem is that the arbitrator has no way of knowing what the default fee level currently is, because it's not provided from their trusted daemon via get_fee_estimate or their own internal wallet.

[iamamyth]

Based on your description, it seems my earlier suspicion would be correct:

I suspect most clients will just call the endpoints in a pair, so splitting them makes net more work for the daemon.

Can you confirm that would be your usage pattern? If so, I think you should just add the default priority to the existing endpoint, for the reasons laid on in my earlier comment.

[woodser]

I think you should just add the default priority to the existing endpoint

What existing endpoint?

[iamamyth]

get_fee_estimate (the only one discussed in this issue).

[woodser]

The priority adjustment code is currently part of wallet2 / monero-wallet-rpc. It would be a much bigger change to move this logic to the daemon and refactor the wallet to use it, than to extend monero-wallet-rpc with an additional call to expose this functionality. If the daemon did support such functionality, we could deprecate this function or refactor it to use the daemon.

[woodser]

But yes I will use the result of get_default_fee_priority to get the index in get_fee_estimate.

[iamamyth]

It would be a much bigger change to move this logic to the daemon and refactor the wallet to use it, than to extend monero-wallet-rpc with an additional call to expose this functionality

Yes, that's fine.