robert

> Imagine, every validator only forwards at most one BackedCandidateInv, or maybe just (CommittedCandidateReceipt, Statements), for each (RelayParentHash, ParaId) I'd answer a slightly different question first: what happens if the...

> If 1/3 of validators wanted to censor a parachain then they might behave worse by stopping approval checks for the parachain Yeah, there are maybe worse things that attacking...

re: https://github.com/paritytech/polkadot-introspector/issues/91 One of the main challenges with these types of closed-topology gossip protocols is observability of network state by external nodes. We should build in some kind of pub/sub...

@sandreim > from an implementation perspective it will be done at the network protocol level, right ? Yeah. Doing this at the network-protocol level opens up more doors for alternative...

@eskimor > Keep alternative paths through the topology open? I assume this is, because the sender would assume we are dead/malicious if we don't fetch otherwise? But still how would...

That is orthogonal. This issue was created in reaction to an incident where an alternative block was built and included a bad parachain candidate. Within 2 seconds of the block...

With paritytech/polkadot#5048 the `included_at` runtime API can be added as a `staging_included_at`.

Revisiting this - I'm no Wasm expert. What can we do to address this?

cc @arkpar you may find this one interesting as well

I don't think we should ever be slashing the parachain's deposit. The other concern I have is that long-running candidates might occupy all of our validation resources, so a shorter...