rpc: Consistent range arguments in scantxoutset/importmulti/deriveaddresses

[sipa]

This introduces a consistent notation for RPC arguments in scantxoutset, importmulti, and deriveaddresses, either:

• "range" : int to just specify the end of the range
• "range" : [int,int] to specify both the begin and the end of the range.

For scantxoutset, this is a backward compatible new feature. For the two other RPCs, it's an incompatible change, but neither of them has been in a release so far. Because of that non-released reason, this only makes sense in 0.18, in my opinion.

I suggest this as an alternative to #15496, which only makes deriveaddresses compatible with importmulti, but not with the existing scantxoutset RPC. I also think [int,int] is more convenient than {"start":int,"stop":int}.

I realize this is technically a feature added to scantxoutset after the feature freeze. If desired, I'll drop the scantxoutset changes.

[gmaxwell]

I like int,int. IIRC scantxoutset is experimental and we shouldn't shy away from breaking it, if we think a change is correct.

[jnewbery]

Concept ACK

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #15427 (Add support for descriptors to utxoupdatepsbt by sipa)

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.

[promag]

Looks good, concept ACK, especially for keeping it compatible.

Is the scantxoutset change worthy a release note?

I also think [int,int] is more convenient than {"start":int,"stop":int}.

The object notation is more verbose, like named arguments, it increases readability.

[sipa]

@promag Added tiny release note.

[Sjors]

utACK

[laanwj]

The object notation is more verbose, like named arguments, it increases readability

Named arguments are useful when there is potential confusion about what the arguments mean, or when there's need for future expansibility. Range notation is kind of self-evident and it's entirely sure that no new fields will be introduced. begin and end adds no information then. It, for example, doesn't tell whether it's an open or closed range. There's only more cognitive overload, more to type and remember.

So I tend to disagree here. A tuple [a,b] is fine, when documented in the RPC help of course.

Concept ACK.

[jonasschnelli]

Concept ACK (also as bugfix for 0.18 to avoid API inconsistency).

[flack]

I realize it's needed for backward compat, but specifying a range by giving one number seems kind of counter intuitive. Esp since by looking at the param, you can't really tell if the one number is supposed to be the start or end of the range (so there's a 50% chance of guessing wrong). Maybe the int version should be restricted to where it's needed for backward compatibility instead of also making it available for the new calls?

[Sjors]

@flack in most cases the start of the range is 0. What I think is more likely to confuse people is that ranges are 0 based, and so 1 means [0, 1] and not [0,0] (I've made this mistake a few times already, although ultimately it didn't really matter).

[flack]

@Sjors interesting, the 0-based part I got right away, but I guess it depends what programming lang you usually work with :-)

What I just find ambiguous is that range: 5 could plausibly be interpreted as either

• range: [0, 5] (i.e. what it really does)
• range: [5, 5] (i.e. give me just one element)
• range: [5, inf] (i.e. start at 5, open-ended)

ofc when you read the documentation, you know that option 1 is the correct one. But as a casual user it's quite easy to make mistakes, since range: 5 is not really self-explanatory

[Sjors]

I would be OK with always requiring both start and end, so [0, 0]. It probably takes less time to type than to interpret the docs :-) Backwards compatibility is not a huge concern because we declared the scan method experimental.

[promag]

So I tend to disagree here. A tuple [a,b] is fine, when documented in the RPC help of course.

@laanwj I didn't say otherwise, just that object notation is more verbose.

[maflcko]

utACK 0fa7e14 (ignore the style-nit)

[Sjors]

rpc/client.cpp needs to be updated for deriveaddresses, otherwise tACK ca253f6.

See: Sjors@349c8cf

[maflcko]

re-utACK ca253f6

Only change since previous review is adding an RPCTypeCheck