Nishant Das

> Message Amplification We have set D to be 8 in the specs which naturally gives us relatively high message amplification. On the block topic (the simplest to reason about),...

> How is message volume related to duplication? Duplication might be the wrong word, but more `IHAVE` messages relaying the same message ids.

2 seems low and might be problematic when trying to sync with in smaller networks. We use a cost based rate-limiter which chooses to rate limit via amount of data...

> We do penalize peers that send attestations that are over this condition (32 slots). We could reduce it with a leniency period where we don't penalize peers in the...

The removing of `net_` dependency would address this issue. For our consensus-specs repo, can we remove references to the network id ? Ex: > https://github.com/ethereum/consensus-specs/blob/dev/configs/mainnet.yaml#L94

> Do other clients have any input here? My main concern would be with penalizing peers with respect to their mesh delivery rate. When we were experimenting with respective parameters...

One advantage of the current strategy is that while subnets are more concentrated, an attestation that is propagated there has a very high likelihood of making it into all the...

This seems like the wrong approach, why do we need to hardcode the timestamp like this ? Why does validator registration require signing a timestamp ?

Hey @houjieth , For the official spec-apis, the deprecated ones are specified here https://ethereum.github.io/beacon-APIs/#/ However for internal prysm apis we don't have an reference/spec for this: https://github.com/prysmaticlabs/prysm/tree/develop/proto/prysm/v1alpha1 @rkapka Do we...

Hey @sragss, the PR partially addresses the issue. It doesn't handle the v1alpha1 endpoints, https://github.com/prysmaticlabs/prysm/tree/develop/proto/prysm/v1alpha1 . However given v1alpha1 is internal to prysm, there is no reference spec to compare...