robert

> We should only fetch & second collations that are either built on top of the root of some fragment tree or have a parent which is backed. I don't...

> Candidate hashes are returned because we may want to keep advertisements in memory until we receive CandidateBacked event. There's already logic for pruning advertisements (quoting from #5054 ): 1....

> This PR targets a different issue, when a collator advertises a collation built on top seconded para head. We would want to keep such advertisements in memory until it...

I amended some language in #5054 which may have been the cause of this confusion: previously: > We should allow collators to make a few (up to MAX_DEPTH?) announcements per...

> GetHypotheticalDepths doesn't give any info about parent nodes being backed Yeah, it always either needed to change or to have some alternative request introduced which serves the same purpose....

I would prefer a more general API which can be used by multiple subsystems. This `IsSecondingAllowed` is not enough for the logic that the collator needs to do, which is...

> Do we need exponential slashing? From an implementation complexity side, it would probably be easier without. 1% is already a pretty high deterrent and client bugs are not unlikely...

> For starters, I'd implement ignoring for the rest of the session. They will be kicked out of the validator set in the next session anyway. Yes, this seems fine....

Could this be solved using hashing in some way? I don't fully understand the control flow but you could probably maintain some map from UTXO proof public-keys to blake32 hashes,...

Posting some notes on a couple questions I was thinking about - large statements, spam, and topology. At the end there is a proposed solution to all the issues. -...