Potuz

Also on this topic, the consumers of these functions are in the blockchain package, via the function `Service.CurrentJustifiedCheckpt()` which does a safe copy. The idea was to move to `forkchoicetypes.Checkpoint`...

Can we block these kinds of changes until after the merge? I'm scared of changes dealing with locks in core code this late in the game

> You are reporting issues using prysm-output. We don't really know prysm that much in depth, so have no idea what prysm was doing when it encountered this error --...

Just a couple of quick comments: The API says `justified_epoch` but uses `$ref: './misc.yaml#/Checkpoint'`. Prysm cannot know the justified checkpoints of the nodes, it does know the justified epoch though....

I feel like other store specifics are universal: the best justified checkpoint, the proposer boost root (perhaps even the previous proposer boost root),

> The prysm structure from the issue suggested you had the checkpoint I thought? > > ``` > message ForkChoiceResponse { > // Latest justified checkpoint in forkchoice store. >...

> @potuz does `weight_mode` make sense to you? I assume the "cumulative-to-root" weight of a node means the sum of all the non-cummulative weights of every descendant (including itself)? Except...

> `effective_ballance` is something very useful IMO, for giving percentages to nodes\heads I think it should be for the justified checkpoint which is what's used in computations and not the...

I'm wondering if it's not worth to have timestamp as a mandatory field in all of the reorgs we've had from mainnet having the timestamp was instrumental to quickly assess...

The one big advantage of having the timestamp on the dump is when using @tbenr viewer: if you order the nodes by timestamp instead of by slot number, you get...