Add a dedicated function to get the tip height and header?

[4c656554]

A suggestion to add a function to get the current best tip (both height and header):

Whilst I think this can be done using the forthcoming get_block_headers_request, it requires processing by the receiver; this would be simpler to use.

Candid:

type bitcoin_block_header = Blob;

type get_tip_result = {
  tip_height: Nat32;
  tip_block_header: bitcoin_block_header;
};

func bitcoin_get_tip(): (get_tip_result);

Alternatively, perhaps changing get_block_headers_request so that, with start_height at 2^{32} - 1 for example, it could yield just the tip.

Finally, perhaps it should also return any competing tips, or some kind of confidence indicator.

Thank you

---

Related:
#297 (comment)
#298
#292
#269

[ielashi]

@THLO WDYT? I believe this request has been re-occurring, and while developers can get this information from a call to get_utxos, it's arguably not intuitive.

[THLO]

Personally, I'd like to have a get_blockchain_state endpoint that returns all kinds of meta information such as the current height, tip block header hash, time, target, and possibly also the fee percentiles (which would imply that there is no need for a dedicated endpoint anymore). What do you think?

[4c656554]

@THLO that sounds like it would work.

Would passing around a larger blockchain_state object incur any significant costs, if heavily used? I am not familiar enough to judge.

Perhaps get_blockchain_state could have default 'True' bool input parameters that, if 'False', results in the omission of the parameters the user is not interested in. Or some equivalent mechanism.

[THLO]

All of the metadata that I mentioned can be encoded in just a few bytes - except for the fee percentiles, which require a few hundred bytes -, so it wouldn't incur any significant costs.
Adding a complex mechanism to filter the desired fields therefore won't be necessary.