aboutsummaryrefslogtreecommitdiff
path: root/doc/release-notes
diff options
context:
space:
mode:
authorPieter Wuille <pieter.wuille@gmail.com>2017-11-10 12:48:00 -0800
committerPieter Wuille <pieter.wuille@gmail.com>2017-11-10 16:12:22 -0800
commit033c78671b91b12d589ebff6c5ede8d94d7500f8 (patch)
tree1955e6f06a668a588e3ab4cea248ed19f258ddaf /doc/release-notes
parent61fb80660f73e5aa5b69302ecc7ac33da206ba5a (diff)
parent11413646be2a6d0bf1c857753bfcec0af60c72b8 (diff)
downloadbitcoin-033c78671b91b12d589ebff6c5ede8d94d7500f8.tar.xz
Merge #11258: [rpc] Add initialblockdownload to getblockchaininfo
11413646b [trivial] (whitespace only) fix getblockchaininfo alignment (John Newbery) bd9c18171 [rpc] Add initialblockdownload to getblockchaininfo (John Newbery) Pull request description: Exposing whether the node is in IBD would help for testing, and may be useful in general, particularly for developers. First discussed in #10357 here: https://github.com/bitcoin/bitcoin/pull/10357#pullrequestreview-59963870 > ... we could simplify this (and possibly other) tests by just adding a way to know if a node is in IBD. I'd like to do that, but I'm not sure it makes sense to complicate this PR with discussion over how that information should be made available. Eg it's not clear to me that the notion of being in IBD is worth exposing to the casual user, versus a hidden rpc call or something, since the definition has changed over time, and may continue to change in the future. But I still do agree that at least for testing purposes it would be far simpler to expose the field somehow... This PR currently implements the simplest way of doing this: adding an `initialblockdownload` field to `getblockchaininfo`. Other approaches we could take: 1. add a new debug RPC method that exposes `IBD` and potentially other information. 2. add a parameter to `getblockchaininfo`, eg `debug_info`, which would cause it to return debug information including IBD 3. add a query string to the url `?debug=true` which would cause RPCs to return additional debug information. I quite like the idea of (3). Feedback on these and other approaches very much welcomed! @sdaftuar @laanwj Tree-SHA512: a6dedd47f8c9bd38769cc597524466250041136feb33500644b9c48d0ffe4e3eeeb2587b5bbc6420364ebdd2667df807fbb50416f9a7913bbf11a14ea86dc0d4
Diffstat (limited to 'doc/release-notes')
0 files changed, 0 insertions, 0 deletions