It looks like that #9614 accidentally(?) dropped support for min-conf
and watch_only
in getbalance()
.
This PR tries to correctly deprecate accounts in getbalance()
following the dummy-argument approach.
It looks like that #9614 accidentally(?) dropped support for min-conf
and watch_only
in getbalance()
.
This PR tries to correctly deprecate accounts in getbalance()
following the dummy-argument approach.
Weird, travis failed with
0/home/travis/build/bitcoin/bitcoin/build/bitcoin-x86_64-apple-darwin11/build-aux/install-sh: src/qt/bitcoin-qt does not exist.
1Makefile:1214: recipe for target 'Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt' failed
2make: *** [Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt] Error 1
3make: *** Waiting for unfinished jobs....
restarted job.
I don’t understand. min-conf
and watch_only
have never been supported when account
is not specified:
0 if (request.params.size() == 0)
1 return ValueFromAmount(pwallet->GetBalance());
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
I’ve taken another look at this and I don’t think that #9614 removed the ability to call getbalance "*" 0 true
. I think it was accidentally removed by #12953 here: https://github.com/bitcoin/bitcoin/commit/109e05dcd163b8ddb7f4b3550db6b9ab833b2c04#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR891.
Concept ACK fixing that regression and restoring the functionality to call getbalance "*" 0 true
.
However, note that calling getbalance "*" 0 true
invokes GetLegacyAddress()
, which ‘calculates the balance in a different way […], and which can count spends twice when there are conflicting pending transactions (such as those created by the bumpfee command), temporarily resulting in low or even negative balances. In general, account balance calculation is not considered reliable and has resulted in confusing outcomes, so it is recommended to avoid passing this argument.’
This PR changes the API to allow getbalance include_watchonly=true
, which will now also call GetLegacyAddress()
. I’m not sure if that’s desirable. At the very least, the help text should make it clear that the balance may not be as expected.
cc @ryanofsky , who wrote that help text.
@jnewbery AFAIK there is currently no “better” balance calculation if one wants to filter with watch-only & min-confirmation-count,… and I think keeping the old behaviour rather then removing it is preferable.
But obviously the whole balance calculation and caching system is inefficient (I guess it’s not buggy?) and needs probably a complete overhaul.
getbalance include_watchonly=true
works, otherwise there’s no way to get the watchonly balance if not using the -deprecatedrpc=accounts
argument. However, the help text needs to be updated to explain that the balance is calculated in a different way if the include_watchonly
parameter is used.
However, the help text needs to be updated to explain that the balance is calculated in a different way if the include_watchonly parameter is used.
I don’t think there’s a technical reason why CWallet::GetBalance couldn’t support the same isminefilter filter
and int minDepth
options that CWallet::GetLegacyBalance
takes. It should just be matter of forwarding the arguments down to CWalletTx::GetAvailableCredit
and adding a few lines of filtering code there. This would probably be less confusing that calculating the balance in a different way when filters are present (and having to explain this in documentation and maybe break compatibility in the future).
Added min/max conf filter for GetWatchOnlyBalance()
and started to use this method for getbalance in conjunction with watchonly. Refactored GetUnconfirmedWatchOnlyBalance()
.
Not sure if this is better since the main goal of this PR is to avoid an API break in 0.17. The balance methods probably need refactoring which is not the main intention here.
Ping @sipa @ryanofsky
Didn’t look extremely close but it seems like 9bbd407936f399c706bbc70c8b5ffa0bba0cfec9 has a few issues:
I’m not sure if my original suggestion was unclear, unworkable, or just not good, but I wonder why this couldn’t just forward filter
and minDepth
options down to GetBalance
GetAvailableCredit
methods and slightly just tweak logic inside to implement them.
Also, this is a minor point, but I think it would be clearer to use boost::optional
(eventually std::optional
) for optional values instead of magic numbers like -1.
I think https://github.com/jnewbery/bitcoin/tree/fix_get_balance does what’s required:
-deprecatedrpc=accounts
is set and getbalance "*" <int> <bool>
is called, then GetLegacyBalance()
is used (unchanged behaviour)getbalance minconf=<int> include_watchonly=<bool>
is called without an account, then GetBalance()
is calledGetBalance()
takes min_conf
and ismine_filter
argumentsinclude_watchonly
is set, the returned value includes GetWatchOnlyBalance + GetBalance.
@ryanofsky - is that what you had in mind?
@jonasschnelli - if you’re happy with that branch, either take it here or let me know and I’ll open a PR.@ryanofsky - is that what you had in mind?
Yes, changes from https://github.com/bitcoin/bitcoin/compare/master...jnewbery:fix_get_balance are what I was suggesting. Some thoughts looking at code:
IsDeprecatedRPCEnabled("accounts")
and the account argument is not null or “*”. Otherwise the argument would be silently ignored.GetAvailableCredit
a little with something like0CAmount* cache = filter == ISMINE_SPENDABLE ? nAvailableCreditCached :
1 filter == ISMINE_WATCH_ONLY ? nAvailableWatchCreditCached :
2 nullptr;
jonasschnelli
promag
laanwj
jnewbery
DrahtBot
ryanofsky
sipa
Labels
Wallet
RPC/REST/ZMQ
Milestone
0.17.0