Potuz

I'll leave the same comment here as in Paul's PR, an option is to process full withrawals in the same loop as effective balance updates. That may be equivalent to...

> At least for Lodestar, (on a preliminary look, not implemented yet) the previous approach won't require a full sweep of the validator set. We do all sweeps in epoch...

One big difference that this PR introduces is that the withdrawal queue is much smaller. This is the first time we have a queue in the specs and I am...

Coming to think about this: if we go with rolling sweeps as in this PR, there's no need for the queue at all: knowing what are the next withdrawal indices...

> This looks largely good to me. Might worth picking it up again CC @kasey will this conflict with your work?

There's a trade-off here in that it's preferable to have attestations with the right target for the current epoch as justification is more important than validator earnings. But it's a...

> I do believe this is already implemented: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/core/altair/attestation.go#L290-L291 The quoted check just checks for the correct source, did you mean something else?

> Correct me if I'm wrong: this participation flag is false if the delay is > 5 slots, hence the attestation will not be processed. > That participation flag is...

This issue is very much still open

> Cool, I think I'm getting close. Similar to the Teku implementation, the filter can be placed prior to block proposal: https://github.com/prysmaticlabs/prysm/blob/develop/beacon-chain/rpc/prysm/v1alpha1/validator/proposer_attestations.go I'd support if there's an earlier path for...