Currently listdescriptors RPC uses next key to represent WalletDescriptor::next_index while importdescriptors uses next_index. This creates two different descriptor formats.
This PR changes listdescriptors to use the same key as importdescriptors.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | aureleoules, achow101 |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
As it's an API change, probably should add it to the release-notes.
1846 | @@ -1847,7 +1847,7 @@ RPCHelpMan listdescriptors() 1847 | range.push_back(info.range->first); 1848 | range.push_back(info.range->second - 1); 1849 | spk.pushKV("range", range); 1850 | - spk.pushKV("next", info.next_index); 1851 | + spk.pushKV("next_index", info.next_index);
There should be some compatibility at least for a release or two.
https://github.com/bitcoin/bitcoin/pull/26194/commits/b9ea106f1da4e018ec4876d8e5b1209401ace382 adds the next_index instead of replacing next as suggested in #26194 (review) for compatibility reasons and adds the release notes as suggested in #26194 (comment).
ACK b9ea106f1da4e018ec4876d8e5b1209401ace382
1771 | @@ -1772,6 +1772,7 @@ RPCHelpMan listdescriptors()
1772 | {RPCResult::Type::NUM, "", "Range end inclusive"},
1773 | }},
1774 | {RPCResult::Type::NUM, "next", /*optional=*/true, "The next index to generate addresses from; defined only for ranged descriptors"},
If this is kept for compatibility, it might be good to mention it, and that the value is equal to the other. Otherwise users might be confused to see the same field twice and wonder what the difference is?
reACK b082f28101773e0ef0281d97025e65d0364d6f29
ACK b082f28101773e0ef0281d97025e65d0364d6f29