[rpc] deriveaddress: rename range 'begin' argument to 'start' #15496
Conversation
|
Pointed out by @instagibbs in the original PR. Would be nice to get this into 0.18. Fixed a grammar nit as well. |
|
utACK 483b1c0 |
After consistency, personally I prefer begin/end and start/stop. |
|
I can change |
|
Good catch. Makes sense to at least be consistent between calls. |
|
utACK 483b1c0 |
|
Given that both |
|
@sipa |
|
@instagibbs Well clearly |
|
@instagibbs See #15497. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
|
Replacing this with #15497 in the 0.18 milestone. |
…ulti/deriveaddresses ca253f6 Make deriveaddresses use stop/[start,stop] notation for ranges (Pieter Wuille) 1675b7c Use stop/[start,stop] notation in importmulti desc range (Pieter Wuille) 4566011 Add support for stop/[start,stop] ranges to scantxoutset (Pieter Wuille) 6b9f45e Support ranges arguments in RPC help (Pieter Wuille) 7aa6a8a Add ParseRange function to parse args of the form int/[int,int] (Pieter Wuille) Pull request description: 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. Tree-SHA512: 1cbebb90cf34f106786dbcec7afbf3f43fb8b7e46cc7e6763faf1bc1babf12375a1b3c3cf86ee83c21ed2171d99b5a2f60331850bc613db25538c38b6a056676
…importmulti/deriveaddresses ca253f6 Make deriveaddresses use stop/[start,stop] notation for ranges (Pieter Wuille) 1675b7c Use stop/[start,stop] notation in importmulti desc range (Pieter Wuille) 4566011 Add support for stop/[start,stop] ranges to scantxoutset (Pieter Wuille) 6b9f45e Support ranges arguments in RPC help (Pieter Wuille) 7aa6a8a Add ParseRange function to parse args of the form int/[int,int] (Pieter Wuille) Pull request description: 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 bitcoin#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. Tree-SHA512: 1cbebb90cf34f106786dbcec7afbf3f43fb8b7e46cc7e6763faf1bc1babf12375a1b3c3cf86ee83c21ed2171d99b5a2f60331850bc613db25538c38b6a056676
8 participants
This changes
range: {begin: ..., end: ...}parameter forderiveaddresstorange: {start: ..., end: ...}to be consistent withimportmulti.