Implement getchaintips RPC

[Sjors]

The Bitcoin Core getchaintips RPC returns the list of known tip candidates, including which ones are considered invalid. This makes is easier for users (and automated systems) to figure out there's a potential consensus issue.

Specifically, ForkMonitor uses this to send out an alert if any block is considered valid by one implementation yet invalid by another.

[Crypt-iQ]

Technically, the block isn't invalid from a consensus PoV, but it's a wire parsing issue which would cause a network split

[Sjors]

I suppose in that case it wouldn't show up as invalid in getchaintips? You'd at least see there's a headers chain with more work that's being ignored.

[Roasbeef]

I suppose in that case it wouldn't show up as invalid in getchaintips?

In the case of the last block, it never made its way to block validation so validity was never able to be determined. Instead the block wasn't decoded, and the peer was disconnected.

[Sjors]

A bit tangential, but if the block is not too large, and if we requested it (after checking the header PoW), and the checksum matches the header, that's probably enough DoS protection to go ahead and pass the block to the validation logic. In which case it would show up in getchaintips (but the original bug wouldn't have happened at all, because it would have passed the validation check).

[kcalvinalvin]

This shouldn't be too difficult to implement. I'll pick this up

[Roasbeef]

and if we requested it (after checking the header PoW), and the checksum matches the header,

btcd understands the sendheaders message, but it never sends it itself. As a result, we only learn about new blocks via the inv hash, so we need to fetch the entire thing to verify it (we don't see the header first).