More economical fee estimates for RBF and RPC options to control

[morcos]

This PR takes advantage of the new fee estimation feature that will potentially give lower estimates if recent market conditions warrant it. The logic used here is that any time a transaction signals opt-in-RBF and uses automatic fee estimation then it will use the non-conservative estimate. Transactions which do not signal opt-in-RBF will still use the default conservative estimate.

In a nutshell conservative estimates require that your fee rate would meet the necessary confirmation threshold for double your target at longer time horizons as well. This reduces the likelihood that you place a transaction just as the market is starting to get busy again that ends up being stuck for a very long time.

This PR also allows the specification of transaction confirmation target and whether the estimate should be conservative or not on a per-RPC call basis for sendtoaddress, sendmany, bumpfee, and fundrawtransaction using optional named arguments.

Left as an exercise to the reader is adding this to GUI functions to send transactions and bump fee.

[RHavar]

Concept ACK, this is really great and something that's been needed for a long time. It'll simplify some of the locking and settxfee stuff I've needed to do.

But it'd be nice if it used an options object or something. Otherwise if I want to specify the conservative_estimate I'll need to fill in all the other fields, which I might not want to know?

But I guess that's something that can be done in a different commit, with if (arguments.length == 3 && typeof arguments == 'object') style

[instagibbs]

@RHavar I had the same exact reaction fwiw. fee_options or something.

[morcos]

I thought the whole point of named arguments is we didn't have to worry about that any more. I think I made sure these work correctly with holes so we can use them with named arguments.

[RHavar]

Oh yeah, you're right. Guess I should learn how to use named arguments.

[sipa]

Needs rebase.

[morcos]

Rebased due to conflict with #10422

[laanwj]

I'd prefer to use a string here (which maps to FeeEstimateMode) instead of a boolean. This would also allow adding additional fee estimation strategies in the future without changing the interface.
(if we keep it this way, it should be documented that this is really a tri-value boolean, where null/unset is auto)

[laanwj]

Concept ACK

[morcos]

Switched to an estimate_mode string and squashed
5cbc1f6 (rpcestimatechoice.ver2) -> 1bc6a4a (rpcestimatechoices.ver2.squash)

[morcos]

Changed argument name from opt_in_rbf to replaceable for conformance with bumpfee

[instagibbs]

utACK ab07a10

[instagibbs]

Not sure this is the best possible name. ConservativeEstimateRequested ?

[morcos]

#10586 (comment)

[instagibbs]

Ok we agree it should be a mode being returned ideally.

[TheBlueMatt]

I think it makes more sense to let it be generic and ideally estimatesmartfee would take a FeeEstimateMode and this functions purpose would be to take any requested mode and other wallet parameters and use wallet logic to determine a final mode. Rather than make all those changes now while not yet needed though, I think I'll just change the RPC interface to conservative estimates to take a string as per #10589 (review)

I stand entirely unconvinced that you shouldn't just do this now - just add more args (or add a struct arg) to GetMinimumFee instead of adding some new function that returns some magic value that you then immediately go and pass into GetMinimumFee everywhere?

[morcos]

Please see #10706
CalculateEstimateType is now only used one place, in GetMinimumFee.

[TheBlueMatt]

I still dont really feel comfortable ACKing the Qt changes until I get a chance to test, but this is generally a very welcome improvement.

[TheBlueMatt]

I think it makes more sense to let it be generic and ideally estimatesmartfee would take a FeeEstimateMode and this functions purpose would be to take any requested mode and other wallet parameters and use wallet logic to determine a final mode. Rather than make all those changes now while not yet needed though, I think I'll just change the RPC interface to conservative estimates to take a string as per #10589 (review)

I stand entirely unconvinced that you shouldn't just do this now - just add more args (or add a struct arg) to GetMinimumFee instead of adding some new function that returns some magic value that you then immediately go and pass into GetMinimumFee everywhere?

[TheBlueMatt]

Nit: no need for the \n here (and a few other similar lines in this file.).

[morcos]

rebased for adjacent line change in #10698 and removed a couple extra \n's

no other changes

I believe we've settled on removing the CalculateEstimateType function entirely at the end of #10706 since it just becomes a helper for GetMinimumFee at that point.

[TheBlueMatt]

Looks good. Definitely want #10706 to go in with this.

[TheBlueMatt]

Cant comment there, but I believe you also need to move the default setting of optInRBF up a bunch here (about 10 lines below this (set default rbf checkbox state, or does that setting automagically result in calling these registrations?).

[morcos]

Not sure if I understand your question (or how QT works) but I'm pretty sure it's correct as is. Calling setCheckState below will trigger the signal if the checkbox changed from its initial value.

[promag]

Either way, what about make an explicit call to coinControlUpdateLabels()?

[morcos]

I don't think this is necessary. It's analogous to setting the default sliderSmartFee done in the same section of code.

[promag]

IMO this would be a cleaner implementation

bool FeeEstimateModeFromString(const std::string& string, FeeEstimateMode& fee_estimate_mode)
{
    // lookup string
    return false;
}

...


if (!FeeEstimateModeFromString(request.params[7].get_str(), coin_control.m_fee_mode)) {
    throw JSONRPCError(RPC_INVALID_PARAMETER, ...);
}

[promag]

Missing new arguments.

[morcos]

will do

[promag]

Add options instead of 3 more optional arguments?

[morcos]

I believe named arguments are preferable

[promag]

I understand, but for those that use indexed arguments, they have to pass the middle arguments.

[promag]

fee_estimate_mode, fee_mode or estimate_mode?

[morcos]

Hmm.. Yes, I think it might make sense to change this to fee_mode, but leave it estimate_mode for estimateSmartFee (done in another PR). Even though they take the same values now, I could imagine they would differ in the future. Any other thoughts?

[promag]

I just wanted to point out the inconsistencies between arguments, variable names and types.

[morcos]

I decided leaving it as estimate_mode in both RPC's is preferable.
The inconsistency between variable and parameter name is not worth the churn imo.

[promag]

Add options instead of 3 more optional arguments?

[promag]

I saw the above comment about named arguments. IMO from the client side feels better as an option.

[promag]

Either way, what about make an explicit call to coinControlUpdateLabels()?

[promag]

m_fee_estimate_mode?

[promag]

IsFeeEstimateConservative?

[morcos]

Function removed in #10706 (or will be shortly)

[promag]

Still, name not clear don't you think?

[morcos]

yeah but who cares, its going away completely in a couple of commits

[morcos]

Took some of the nits
(rpcestimatechoice.ver3) -> f135923 (rpcestimatechoices.ver3.squash)

[ryanofsky]

utACK f135923

[promag]

As suggested in another PR, the first condition can be removed since UniValue::operator[] handles out of bounds. Same below.

[laanwj]

utACK f135923