Jeff Burdges

A priori, we should avoid randomness here since on-chain randomness is biasable. It makes analyzing this annoying and appears non-essential. I've not thought much about it though, so if it's...

> I am still a little uncomfortable with the notion of disabling validators who haven't been 100% slashed in order to protect them from bugs when they can always ask...

We'll need more nuanced disabling here because we cannot really limit the number disabled. We should take discuss a hybrid scheme: If a backer votes come back invalid then -...

Ain't clear if "doppelganger" really makes sense: Who runs the node? How much do differences matter? Does minimizing differences represent the adversarial enviroment of the real polkadot? etc. We should...

> This is an interesting idea and would be actually cool. Alright another idea.. We create a special test class of parachain on kusama & polakdot themselves, which work exactly...

Do we know how much time gets spent in `Crypto` vs hashing? We cannot just return true in hashing since runtimes compare results. This'll be true of future crypto too,...

It's tricky to do so, but in principle audits permit alterations to the runtime & memory constraints of a system parachain, including NPoS elections. We do not yet have validator...

We should still explore switching to https://github.com/AndersTrier/reed-solomon-simd since it seems much faster than our own reed-solomn crate. > each backer is only used for one systematic chunk, to not overload...

As a rule, the keypair is the secret key type and the actual private key type should never be used. It's okay to use the private key type for serialization...

It's fine to separate them for user facing js things that do not require high performance, just provide a sign function that calls `.to_public()` or `.expand_to_public()`. Anytime you want high...