Jeff Burdges

Also, we researchers suggested significantly more than just this doubling of the delay in our analysis in https://github.com/paritytech/polkadot/pull/1656 like 6 x I think. We should avoid the need for that...

We've this intermediate "valid but too slow" mode discussed in https://github.com/paritytech/polkadot/pull/1656 I presume the 6x in https://github.com/paritytech/polkadot/pull/5951 does not bring this distinction in? @AlistairStewart and I were recently leaning towards...

> If by "valid but too slow" you mean candidates that takes to validate somewhere in between 2s and 12s, we currently accept them. Backers who fail to validate a...

Cool thanks. We can discuss "valid by slow" messages by approval checkers if https://github.com/paritytech/polkadot/pull/5951 does not suffice for the current problems, but no point worrying just yet. :)

Are `View`s also tracking nodes assigned roles? We'd presumably send initial backing statements only to other backers, and only gossip double backing statements to everybody, for example.

What about grandpa's gossip topology? I think four random peers does not sound wonderful, either for latency, deduplicaiton, etc. What if we used the grid from approvals?

Alright first.. [Our erasure coding is systemic](https://github.com/drahnr/rs-ec-perf/blob/master/reed-solomon-novelpoly/src/field/inc_encode.rs#L32), meaning chunks `0..f+1` represent an exact copy of the block. We should add this optimization into the decoder @drskalman. If you simply define...

Second.. Your protocol is not secure because summing hashed-to-curve points does not act like an accumulator. `H_fake = [ \sum_i \mathcal{H}(C_i) ] - \mathcal{H}(C_fake)` falsely claims `C_fake` to be a...

Yes, cool. We could exploit our erasure coding being systemic to streamline fetching PoVs. It gives a clean failover from direct fetching to reconstruction.

Yes, something like `chunk_index = validator_index + parachain_id + relay_parent_slot_no % num_validators` like I noted above.