/bitcoin

Better API for estimatesmartfee RPC #10707

Merged
merged 2 commits into from Jul 17, 2017

Conversation

Reviewers

@sipa sipa

@TheBlueMatt TheBlueMatt

@promag promag

@ryanofsky ryanofsky

@gmaxwell gmaxwell

Assignees
No one assigned
Labels
RPC/REST/ZMQ TX fees and policy
Projects
None yet
Milestone
  0.15.0
8 participants
@morcos @sipa @ryanofsky @TheBlueMatt @gmaxwell @promag @fanquake @jonasschnelli
@morcos
Contributor

morcos commented Jun 29, 2017 • edited

Through 0.14 branch, the estimatesmartfee API was tagged "WARNING: This interface is unstable and may disappear or change!" and this warning is removed for 0.15, so any wanted API updates should happen now.

The changes here are to make the additional parameter for conservative estimates a more general estimate_mode string , to omit the feerate and include an error string instead of returning -1 on error, and to do better parameter checking initially.

It is only the last 2 commits, but it's built on #10706 and #10543.

See #10707 (comment) for renaming of nblocks argument to conf_target. Will need to be included before string freeze.

PR description edited for clarity

morcos referenced this pull request Jun 29, 2017

Closed

Add allowable range to estimatesmartfee RPC help #10654

@fanquake fanquake added RPC/REST/ZMQ TX fees and policy labels Jun 30, 2017

jonasschnelli added this to the 0.15.0 milestone Jul 6, 2017

src/rpc/mining.cpp
- " feerate and is more likely to be sufficient for the desired target, but is not as\n"
- " responsive to short term drops in the prevailing fee market\n"
+ "1. nblocks (numeric) Confirmation target in blocks (1 - 1008)\n"
+ "2. \"estimate_mode\" (string, optional, default=CONSERVATIVE) The fee estimate mode.\n"
@morcos

morcos Jul 10, 2017

Contributor

s/conservative/estimate_mode/ 7 lines up..

@morcos

morcos Jul 11, 2017

Contributor

done

TheBlueMatt referenced this pull request Jul 11, 2017

Open

TODO for release notes 0.15.0 #9889

0 of 10 tasks complete
@sipa
Owner

sipa commented Jul 11, 2017

Needs rebase.
@morcos
Contributor

morcos commented Jul 11, 2017

Rebased correctly for #10589 merge
@morcos
Contributor

morcos commented Jul 12, 2017

Clean rebase again for changes to #10707

Added a new optional commit which changes the named arguments in estimatesmartfee and estimaterawfee from nblocks to conf_target. estimaterawfee is new for 0.15 and estimatesmartfee was previously labeled unstable. I think it makes sense to align the argument names here with the ones used in fundrawtransaction, sendtoaddress, and sendmany. Those 3 wallet RPC calls only got this new argument for 0.15, but I think conf_target is far superior to nblocks. Note that bumpfee was already released with confTarget however. estimatefee is left unchanged as it is deprecated.

I don't feel strongly about this change, but if we want to align the argument names, now is the time to do it.
@ryanofsky
Contributor

ryanofsky commented Jul 13, 2017

It is only the last commit, but it's built on [...]

Looks like it's the last two commits now, for anyone else looking at this.
@ryanofsky

ryanofsky reviewed Jul 13, 2017
View changes

utACK 7d70bb7. Should update PR description to mention conf_target renames before this is merged.

morcos referenced this pull request Jul 13, 2017

Merged

Improve wallet fee logic and fix GUI bugs #10706

@morcos
Contributor

morcos commented Jul 14, 2017

rebased on new #10706, no changes
src/rpc/mining.cpp
+ " Whether to return a more conservative estimate which also satisfies\n"
+ " a longer history. A conservative estimate potentially returns a\n"
+ " higher feerate and is more likely to be sufficient for the desired\n"
+ " target, but is not asresponsive to short term drops in the\n"
@sipa

sipa Jul 15, 2017

Owner

Typo: asresponsive

src/rpc/mining.cpp
"\nResult:\n"
"{\n"
- " \"feerate\" : x.x, (numeric) estimate fee-per-kilobyte (in BTC)\n"
+ " \"feerate\" : x.x, (numeric, optional) estimate fee-per-kilobyte (in BTC)\n"
+ " \"errors\": [ str... ] (json array of strings, optional) Errors encountered during processing\n"
@sipa

sipa Jul 15, 2017

Owner

Why are these not RPC errors?

@morcos

morcos Jul 15, 2017

Contributor

The whole command is not necessarily an error. It's just an error in returning a value for that particular horizon. It was my understanding that this was the preferred method rather than silently omitting the horizon. Also there is no error with the request.

Or am I misunderstanding your question?

@sipa

sipa Jul 16, 2017

Owner

I see. It makes sense that no RPC error is to be returned for cases where it is not due to something the caller could know. It still seems overkill to create a whole new errors field for just a lack of available information, though. Do we expect more kinds of errors to be added later?

@morcos

morcos Jul 16, 2017

Contributor

I had originally thought I'd be able to distinguish between "insufficient data" and "enough data but no passing feerate" (to the extent those are really different things) but it wasn't easy. However I do like the idea of setting the API now to be general enough that we don't have to change the API in the future if suppose we want to give an answer but also give an errors indicating part of the calculation couldn't work or something.

Also estimaterawfee now is merged to master with a similar errors field.

In short, I don't know that there will be more kinds, but I also don't see much harm in adding the errors field. If users don't care they can just ignore it right?

@promag

promag Jul 16, 2017

Contributor

In terms of REST, the status code can represent both situations. In this case it could be a 412 Precondition Failed with { "message": "Insufficient data or no feerate found" } as body instead of a 200 with an error body. Not sure if it can be like that with RPC.

@sipa

sipa Jul 17, 2017

Owner

We have RPC error codes, but those are usually for exceptional situations, rather than to communicate a totally inevitable not-enough-data situation.

src/rpc/mining.cpp
+ if (!(feeRate == CFeeRate(0))) {
+ result.push_back(Pair("feerate", ValueFromAmount(feeRate.GetFeePerK())));
+ }
+ else {
@sipa

sipa Jul 15, 2017

Owner

Nit: else on the same line as }

src/rpc/mining.cpp
"\nResult:\n"
"{\n"
- " \"feerate\" : x.x, (numeric) estimate fee-per-kilobyte (in BTC)\n"
+ " \"feerate\" : x.x, (numeric, optional) estimate fee-per-kilobyte (in BTC)\n"
+ " \"errors\": [ str... ] (json array of strings, optional) Errors encountered during processing\n"
@promag

promag Jul 16, 2017

Contributor

In terms of REST, the status code can represent both situations. In this case it could be a 412 Precondition Failed with { "message": "Insufficient data or no feerate found" } as body instead of a 200 with an error body. Not sure if it can be like that with RPC.

src/rpc/mining.cpp
- CFeeRate feeRate = ::feeEstimator.estimateSmartFee(nBlocks, &feeCalc, ::mempool, conservative);
- result.push_back(Pair("feerate", feeRate == CFeeRate(0) ? -1.0 : ValueFromAmount(feeRate.GetFeePerK())));
+ CFeeRate feeRate = ::feeEstimator.estimateSmartFee(conf_target, &feeCalc, conservative);
+ if (!(feeRate == CFeeRate(0))) {
@promag

promag Jul 16, 2017

Contributor

operator!=.

@morcos
Contributor

morcos commented Jul 17, 2017

Rebased now that #10706 is merged. Typo fixed in the comments, 2 white space changes and !(feerate == CFeeRate(0)) changed to feerate != CFeeRate(0)
@gmaxwell

gmaxwell approved these changes Jul 17, 2017
View changes

utACK

@ryanofsky

ryanofsky reviewed Jul 17, 2017
View changes

utACK a9ee31a. Only changes since previous review were rebase, switching to operator != and fixing whitespace around else.

morcos added some commits Jun 29, 2017

@morcos morcos Improve api to estimatesmartfee 
Change parameter for conservative estimates to be an estimate_mode string.
Change to never return a -1 for failure but to instead omit the feerate and
return an error string.  Throw JSONRPC error on invalid nblocks parameter.
 439c4e8
@morcos morcos Convert named argument from nblocks to conf_target 
in estimatesmartfee and estimaterawfee.  Also reuse existing bounds checking.
06bcdb8
@morcos
Contributor

morcos commented Jul 17, 2017

Added 2 more lines of RPC help.

(smartapi.ver2) -> 06bcdb8 (smartapi.ver2.squash)
@TheBlueMatt
Contributor

TheBlueMatt commented Jul 17, 2017

utACK 06bcdb8
@ryanofsky

ryanofsky reviewed Jul 17, 2017
View changes

utACK 06bcdb8, only change is help text

@gmaxwell

gmaxwell approved these changes Jul 17, 2017
View changes

reACK

src/rpc/mining.cpp
@@ -806,42 +806,59 @@ UniValue estimatesmartfee(const JSONRPCRequest& request)
{
if (request.fHelp || request.params.size() < 1 || request.params.size() > 2)
throw std::runtime_error(
- "estimatesmartfee nblocks (conservative)\n"
+ "estimatesmartfee conf_target (\"estimate_mode\")\n"
@promag

promag Jul 17, 2017

Contributor

Nit, missing space inside (),

@TheBlueMatt

TheBlueMatt Jul 17, 2017

Contributor

Since when do we add a space inside ()s?

src/rpc/mining.cpp
}
UniValue result(UniValue::VOBJ);
+ UniValue errors(UniValue::VARR);
@promag

promag Jul 17, 2017

Contributor

Nit, move to else block below.

src/rpc/mining.cpp
- CFeeRate feeRate = ::feeEstimator.estimateSmartFee(nBlocks, &feeCalc, conservative);
- result.push_back(Pair("feerate", feeRate == CFeeRate(0) ? -1.0 : ValueFromAmount(feeRate.GetFeePerK())));
+ CFeeRate feeRate = ::feeEstimator.estimateSmartFee(conf_target, &feeCalc, conservative);
+ if (feeRate != CFeeRate(0)) {
@promag

promag Jul 17, 2017

Contributor

Suggestion for future PR, CFeeRate constructor argument could have default value = 0 so CFeeRate() sounds more like null fee rate.

src/rpc/mining.cpp
- RPCTypeCheck(request.params, {UniValue::VNUM});
-
+ RPCTypeCheck(request.params, {UniValue::VNUM, UniValue::VSTR});
+ RPCTypeCheckArgument(request.params[0], UniValue::VNUM);
@sipa

sipa Jul 17, 2017

Owner

Isn't this redudant, and already checked on the line above?

@sipa

sipa Jul 17, 2017

Owner

Nevermind.

@sipa
Owner

sipa commented Jul 17, 2017

utACK 06bcdb8

@sipa sipa merged commit 06bcdb8 into bitcoin:master Jul 17, 2017
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@sipa sipa added a commit that referenced this pull request Jul 17, 2017

@sipa sipa Merge #10707: Better API for estimatesmartfee RPC 
06bcdb8 Convert named argument from nblocks to conf_target (Alex Morcos)
439c4e8 Improve api to estimatesmartfee (Alex Morcos)

Pull request description:

  Through 0.14 branch, the estimatesmartfee API was tagged "WARNING: This interface is unstable and may disappear or change!" and this warning is removed for 0.15, so any wanted API updates should happen now.

  The changes here are to make the additional parameter for conservative estimates a more general estimate_mode string , to omit the feerate and include an error string instead of returning -1 on error, and to do better parameter checking initially.

  ~It is only the last 2 commits, but it's built on #10706 and #10543~.

  See #10707 (comment) for renaming of nblocks argument to conf_target.  Will need to be included before string freeze.

  PR description edited for clarity

Tree-SHA512: 6d8ebee8bb410e2950ffd59663eebfed8d1611d995dc935bb91e430d9da7e2f306796f45631458376027d26341c660f09e825e61748103d2f2736ec6dc3df3ae
This commit was signed with a verified signature.
@sipa sipa Pieter Wuille
GPG key ID: A636E97631F767E0 Learn about signing commits
75b5643
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment