[rpc] Add initialblockdownload to getblockchaininfo

[jnewbery]

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: #10357 (review)

... 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

[laanwj]

Concept ACK

3. add a query string to the url ?debug=true which would cause RPCs to return additional debug information.

I don't like adding query string arguments to the RPC mechanism. This would add yet another way of passing in arguments, which is confusing, IMO. If this is to be made optional, adding an optional debug argument to get*info seems to be a better way, as it works within the system.

[TheBlueMatt]

utACK eb45b17

[MarcoFalke]

Maybe just mention that the meaning may change any time and it is only meant for debugging?

[promag]

I think it is useful in general.

[laanwj]

I agree with @MarcoFalke, even though it might be useful in general this should mention that the interpretation (and possibly even use) of this is internal and subject to change.

[promag]

Concept ACK.

[promag]

s/mode/state?

[promag]

Nit, align descriptions 🙄.

[promag]

Instead of multiple assert str in res, how about assert_equal(res.keys(), ...)? This way if someone adds a new response field or changes the response, it must update this tests too.

So only assert known values, and exact keys.

[promag]

Another approach is to create the generic read-only calls:

• liststates returns an array of state names that can be queried;
• querystate state_name returns the state value;
• waitstate state_name (timeout) waits for state change or timeout and returns the state value;

In this case: bitcoin-cli querystate initialblockdownload.

Well, just an approach as @jnewbery asked 😄.

[laanwj]

@promag The idea is ok, though one problem is that that creates cross-cutting RPC calls, whereas we've been moving to subsystem-specific ones for a while (this was one of the reasons to get rid of the generic getinfo).

[promag]

one problem is that that creates cross-cutting RPC calls

I don't agree with that, it only forces the same RPC API for all states, but each subsystem deals with it's states, it's not like getinfo which is a mix of data.

So there would be a middleware where each subsystem must declare the available states and the RPC handler just delegates the state evaluation there.

In other words, I also disagree with having fat RPC's, but I agree with one horizontal API. For instance, the config is horizontal for all subsystems.

[gmaxwell]

Concept ACK but I'm somewhat concerned that IsInitialBlockDownload means something that is not equal to what the user means by "in initial block download". A node is unable to know if its caught up or not, and this is a somewhat reliable heuristic. But for example, if you have a node partitioned off on some fork or something it may well return false here. The concern might be addressable by just throwing the word "estimated" or similar in there somewhere.

[morcos]

ACK eb45b17

I agree slightly better to add some warning to the description of IBD, but that's a nit as far as I'm concerned

[jnewbery]

• Added wording "The use and interpretation of this property may change between releases."
• added whitespace-only commit to fix up alignment for help text
• rebased on master

[MarcoFalke]

Please remove the [WIP], when ready for review/merge

[jnewbery]

Ready for review/merge. PR title updated.

Travis failed for The command "if [ -d ~/.bitcoin ]; then false; fi" exited with 1. Does the cache need to be cleared?

[sipa]

@jnewbery Rebase to fix that.

[MarcoFalke]

This was already rebased and we have the rm -rf in travis' yaml. I think the issue needs more investigation. (Might want to revert from the travis' yaml temporarily).

[jnewbery]

Rebased.

I've updated the help text to:

"initialblockdownload": xxxx, (bool) (debug information) estimate of whether this node is in Initial Block Download mode.

to address Greg's comment: #11258 (comment)

No functional changes.

I think this is ready for merge.

[jnewbery]

Silent rebase conflict. Should be fixed now

[luke-jr]

The current commits only add comments to the functional test (claiming it tests it), but doesn't actually add any tests...?

[jnewbery]

The current commits only add comments to the functional test (claiming it tests it), but doesn't actually add any tests...?

https://github.com/bitcoin/bitcoin/pull/11258/files#diff-31748911f612ce1d09bc82d04f452592R62 adds initialblockdownload to the expected keys returned in getblockchaininfo

[promag]

Unless @luke-jr expects a test for the value.

[jnewbery]

Unless @luke-jr expects a test for the value.

Almost none of the fields from getblockchaininfo are tested for value. PRs welcome to change that.

It's slightly frustrating that this is a minimal functionality PR that has been open for 2 months, ACK'ed by several people, rebased many times, and is now getting nitted because the test coverage for the new functionality doesn't exceed the test coverage for existing functionality. The fact that we're getting down to these micronits suggests it's time to merge this PR (or abandon it).

[achow101]

utACK 1141364