Add getblockheader RPC call

[petertodd]

Alternative to getblock that works even when the block itself has been pruned, returning all available information. Right now the fact that you can't get this information in pruned mode makes pruned nodes quite a bit less useful for some applications.

[laanwj]

Not against this, but you can get already get block headers using REST /rest/headers/<count>/<hash>.<ext>.

[jonasschnelli]

Also not against this, but i think public blockchain data like blocks (headers), transactions or UTXO queries should go over REST instead over an authenticated RPC call. This would follow a more logical design.

Nevertheless, this can be useful because we never merge JSON support for REST Headers (https://github.com/bitcoin/bitcoin/pull/5486/files).

What about getting more in line with REST and also support requesting more than one header (/rest/headers/***<count>***/<hash>.<ext>.)?

[jgarzik]

That's the general goal of REST - querying public, unauthenticated blockchain data from the blockchain engine. Seems better placed there, than RPC.

[paveljanik]

This allows you to get the needed information directly from the Debug window/Console without the needed hackery around the -rest cmdline etc. Very useful! Thanks Peter.

utACK

[laanwj]

There's a strong overlap with #5486 here - even the function is called the same. This does expose a few more values, also derived ones like confirmation and chainwork.

[laanwj]

Tested ACK

[petertodd]

@jgarzik Re: "unauthenticated" data, remember that this is trusted data in the sense that the client would be trusting the full node's opinion on what the valid chain is; I'm not sure I'd use the term "unauthenticated" in describing that, rather, public and trusted.

[dcousens]

Needs to be updated in the docs?