Add query options to listunspent RPC call

[pedrobranco]

This PR adds a new optional JSON options for listunspent RPC call:

• Return unspents greater or equal than a specific amount in BTC: minimumAmount (default = 0).
• Return unspents lower or equal than a specific amount in BTC: maximumAmount (default = MAX_MONEY = 21000000.0 BTC).
• Return unspents with a total number lower or equal than a specific number: maximumCount (default=0=unlimited).
• Return unspents which total is greater or equal than a specific amount in BTC: minimumSumAmount (default = MAX_MONEY = 21000000.0 BTC).

> bitcoin-cli help listunspent
...
5. query options    (json, optional) JSON with query options
    {
      "minimumAmount"    (numeric or string, default=0) Minimum value of each UTXO in BTC
      "maximumAmount"    (numeric or string, default=21000000=unlimited) Maximum value of each UTXO in BTC
      "maximumCount"     (numeric or string, default=0=unlimited) Maximum number of UTXOs
      "minimumSumAmount" (numeric or string, default=21000000=unlimited) Minimum sum value all UTXOs in BTC
    }
...

When selecting unspents on client side in a wallet with a large set of small unspents makes the call listunspent slow. Using with minimumAmount option could improve the performance of the RPC call, performance which depends on the size of wallet, the distribution of the unspents and the minimumAmount selected.

Example:

> bitcoin-cli listunspent 0 9999999 '[]' true '{ "minimumAmount": 10, "maximumAmount": 80, "minimumSumAmount": 50, "maximumCount": 3 }'

Note: this PR also changes/simplifies the code in AvailableCoins to make the longest calls later in execution time, which also could improve performance in some listunspent results.

[laanwj]

Concept ACK

[pedrobranco]

WDYT of adding new options like maximumAmount (which ables to define a range with minimumAmount) or maybe sumAmount (return unspents until the respective sum is bigger than sumAmount) ?

[laanwj]

Yes, would make sense. Passing the JSON "query object" is a good idea.

[pedrobranco]

I'm willing to implement I've also implemented maximumAmount, minimumSumAmount and maximumCount options.

minimumAmount and maximumAmount are options to filter unspents, but maximumCount and minimumSumAmount are grouping options which returns unspents until satisfies one of these conditions.

[luke-jr]

utACK code, one nit.

[luke-jr]

Instead of the dual meanings, just say default=unlimited (and make sure 0 doesn't behave in such a manner).

[pedrobranco]

👍

[pedrobranco]

@laanwj @luke-jr Is this PR mergeable as is?

[laanwj]

Looks like it! but as we're past the feature freeze for 0.14 and this is a new feature, merging this will have to wait until 0.14 is branched off.

[pedrobranco]

About tests: there aren't any tests specifically for testing listunspent options. Should we now create them?

[laanwj]

Yes, tests for that would be great. They'd make it possible to automatically detect when something breaks this functionality.

[kallewoof]

Need to add options to the first line, e.g.

"listunspent ( minconf maxconf  [\"addresses\",...] [include_unsafe] [options] )\n"

[kallewoof]

Typo: [...]Minimum sum value of all UTXOs in " (missing of).

[kallewoof]

Maybe I'm misreading, but this (nMinimumSumAmount) sounds like a maximum, not a minimum. Esp. since it defaults to MAX_MONEY rather than 0.

[pedrobranco]

I see no issue here since is to be used like it was a minorant set of unspents which satisfies the passed value. If It it was called maximum it should not retrieve unspents which sum are greater than the passed value.

[kallewoof]

You are collecting the sum of the nValue and once the total exceeds the minimum you stop. Generally speaking,

int minimumSum = 5;
int values[] = {1,2,3,2,3};
int sum = 0;
for (int i = 0; i < 5; i++) {
  sum += values[i];
  if (sum >= minimumSum) break;
}

The above looks inverted to me, and will no doubt confuse the user. If you used the word minorant, it might help, but the minorant would be the vout set not the sum, I believe?

Anyway, if I'm the only one bothered by this feel free to keep as is.

[pedrobranco]

@kallewoof Any suggestions? nTargetSumAmount?

[kallewoof]

@pedrobranco I say keep it as it is if no one else complains.

[pedrobranco]

Yes, tests for that would be great. They'd make it possible to automatically detect when something breaks this functionality.

@laanwj I'm already working on it. Can I submit in another PR?

[fanquake]

This needs a rebase. @pedrobranco Tests could be submitted in a follow-up PR.

[pedrobranco]

Ready.

[pedrobranco]

Any thoughts if this is going to be merged? /cc @laanwj

[laanwj]

Not necessary in this pull, but if we keep extending these arguments I think it'd be better to group then into a CoinConstraints structure and pass that in.

Speaking of which - isn't CCoinControl pretty much that?

[promag]

@laanwj I agree with creating a structure and grow there.

[laanwj]

Merged (and rebased) via 9390845

[pedrobranco]

Thank you @laanwj 👍

[sipa]

@laanwj I suppose you forgot to close after merging?

[laanwj]

Yes, did'nt automatically happen as I did a rebase locally. Thanks

…

On May 18, 2017 2:38 AM, "Pieter Wuille" ***@***.***> wrote: @laanwj <https://github.com/laanwj> I suppose you forgot to close after merging? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8952 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHutptwk3F7P5M0nGbOo-1CacVVlXtZks5r65L5gaJpZM4KZrh9> .