Expose root or previous hash in block http api

[jaspervdm]

After a testnet4 hardfork (or later), block headers will no longer contain a previous hash, and instead only prev_root (see https://github.com/mimblewimble/grin/issues/1726). It would be convenient if the HTTP API for blocks either still contain previous, or alternatively root (or both) since that would allow services running on top of a Grin node to easily make the link to the previous block, without having to maintain their own MMR.

Related discussion on Gitter:

jaspervdm @jaspervdm 17:45
@antiochp is a prev_root and a hash enough to calculate a new root? or do you need the whole mmr
the reason i'm asking is because if i understand correctly at some point the previous hash will be removed from the block header, but for grinscan (and possibly other explorers) it would be useful to have. if there is an easy way to calculate it, i can already implement it in my code. if you need more information (the mmr) i can't really do that because i'm not tracking it. in that case, maybe we could still output it in the http api, even though it is no longer part of the header itself

Antioch Peverell @antiochp 18:19
@jaspervdm you would need the whole MMR (technically just the set of peaks under the root) to calculate a new root

jaspervdm @jaspervdm 18:19
okay, that's what i thought yea

Antioch Peverell @antiochp 18:20
but for each header you can generate the root and presumably the explorer db could index headers by the root (which would in turn be the prev_root on the next header)
which is how we're potentially going to index them internally in the node
i.e. each header has a root (not stored on the header itself) and a prev_root (stored on the header)

jaspervdm @jaspervdm 18:21
would it be an option to add the root to the http api?

Antioch Peverell @antiochp 18:22
need to think about it a bit but yeah we could expose either root or previous on the http api (you definitely need one of these)

jaspervdm @jaspervdm 18:23
im just trying to avoid that i have to maintain my own mmr

Antioch Peverell @antiochp 18:23
not sure which would be most appropriate here
yeah absolutely - that should be maintained purely in the node itself
can you open an issue to track this so we don't forget?

jaspervdm @jaspervdm 18:24
but i think exposing only 1 of the 2 in the api (like it is now, only prev_root is there) is not enough when the previous hash is no longer in the header
sure, will do

Antioch Peverell @antiochp 18:24
you would have hash + prev_root + previous or hash + prev_root + root

jaspervdm @jaspervdm 18:25
ah yes, either of those would work

Antioch Peverell @antiochp 18:25
I suspect previous makes more sense in terms of the api here
the rest is kind of implementation detail
and not having previous just makes things more complicated

jaspervdm @jaspervdm 18:26
yeah, but either way previous will be removed from the header itself right?

Antioch Peverell @antiochp 18:26
yes that's what we are thinking right now (its a somewhat redundant 32 bytes we can save)
but removing it adds this kind of complexity
which we're going to need to deal with internally as well as externally via the api

Ignotus Peverell @ignopeverell 18:28
and the API can still return previous, so others don't have to maintain that index as well

[antiochp]

API has previous on the header. See #1836 (we decided not to remove it after all).

[antiochp]

without having to maintain their own MMR.

@ignopeverell pointed out this is desirable for clients receiving headers and blocks via broadcast on the network, not just api clients.