Jernej Kos

On the seed node side the following happens (in this case `c1120a71e92eb601c69ce119aef109b05db568d0` is the peer that fails to get any peers from the seed node): ``` {"caller":"service.go:138","impl":"Peer{MConn{127.0.0.1:40622} c1120a71e92eb601c69ce119aef109b05db568d0 in}","level":"info","module":"tendermint:switch","msg":"Starting Peer","peer":"[email protected]:40622","ts":"2020-01-13T10:06:28.412555307Z"}...

Is this a response to my "Not obvious why this happens."? Sorry, that should have been said more clearly, the non-obvious part is why the connection fails in such a...

> if then for some reason the dialing node couldn't connect to any of the peers returned by the seed node In this case it would still update the address...

Hm, so dialing peers should already be throttled, but the test harness (note that this issue is specifically for E2E tests) spins up many nodes at once so maybe this...

All runtime-related slashing conditions (and thresholds to run nodes) should probably be configurable per-runtime.

In addition to slashing, misbehaving nodes should also be frozen (similar to how validators are frozen for double signing), with freezing maybe being configurable per runtime (maybe in addition to...

This should be expanded to include reproducible runtime builds (probably the same environment should be used for both) to ensure that you can reproduce the exact MRENCLAVE.

There is now a [documented](https://docs.oasis.dev/oasis-sdk/guide/reproducing) way to build ParaTimes in a reproducible manner. The same builder environment could be reused for Oasis Core as well.

> CURRENT PROBLEM: For some reason that currently escapes me, the resulting binaries, when built on GitHub CI infrastructure yield different hashes than the ones I obtained on my laptop....

Yes, that's what I meant when I said the current process that simply uses a Docker container is not ideal (eg. some deps aren't pinned). My suggestion was to have...