Michael Sproul

We do close the keystore files after reading them, I think the issue you're encountering is due to the `.lock` file that we open for each keystore. This prevents accidental...

This is indicative of a CPU or I/O bottleneck usually. It doesn't mean your node is inviable but it will probably lead to suboptimal validator performance if you are running...

This is also part of the consensus context on `tree-states`, maybe we should work together to pull that out and consolidate it with this and https://github.com/sigp/lighthouse/pull/3263?

As you may have already discovered, it does not do any magic in networking land 😅 Maybe we can merge this PR almost as-is and I can open a follow-up...

> Fix the error response in lighthouse to return InvalidToken only for actual jwt errors. What do you mean by an _actual_ JWT error? Ideally I think we should log...

Sorry about the missed attestations, we'll be working on several optimisations to make all of this a bit smoother. What hardware are you running on, and which execution client are...

@PanosChtz You can try to improve your situation slightly by adding `--disable-lock-timeouts` to your beacon node flags. This will stop the Pi from getting stuck in a retry loop as...

> Does not appear to be CPU or memory bound, as far as I can tell. @onyxrev It appears that I/O is the biggest bottleneck in cases like this, although...

@gamell Please try upgrading to Lighthouse v3.1.2 and setting `--prune-payloads false`. This will alleviate some of the load on your execution node.

Seems like it should be a straight-forward fix. We're pretty flat out on getting ready for the merge but can probably squeeze it in for v3.1.1. I'll have a go...