Lion - dapplion

@matthewkeil got it! Thanks for looking into this. Closing issue since them it's likely caused for other factors on hardware. We can revisit latter if we have more evidence

Metrics from the original issue show that the lower resolution is not being used. Not sure @michaelsproul if you need 5ms resolution, otherwise the metric lin range could be of...

@AgeManning If ok I can take this issue. Should I build off master or episub? If the latter please link the branch.

I've pushed a branch that consumes the signed peer records on handle_prune, and forwards the addresses to the dialer if any. https://github.com/libp2p/rust-libp2p/compare/master...dapplion:rust-libp2p:px-consume that would cover the client side of the...

Should the consumer side be implemented now? It's pretty easy given the existing from https://github.com/libp2p/rust-libp2p/pull/2107 and does not require to maintain and peer records book

I have some comments to tagging with an integer score: - For existing PRs the chosen values appear quasi random, since it's very hard to quantify this concept - The...

@macladson can you cherry-pick this commit? I have fixed conflicts with unstable, mainly adding the new lightclient fork-types https://github.com/dapplion/lighthouse/commit/21dadec42a63606db9267ea315af1a7daca265aa

AFAIK most clients expose their client name by default via the identify protocol. It's been very helpful to debug bugs while there's no evidence of attacks using it. Should we...

To resolve the issue we can either: - Do nothing an not mention the existence of the identify protocol in the spec - Align with reality and include a line...

Worth it to raise the issue in the beacon APIs specs. There has been similar discussions for the case of missed slots. Would having different HTTP status code serve your...