Igor Żuk

I've tracked the inherents validation down to `substrate/frame/timestamp/src/lib.rs:214` (`::check_inherent`). It looks like we're only protecting ourselves from blocks with timestamps in the future. If you mine a block for a...

> on export (...) we essentially require the user to remember the name of their key-pairs What's wrong with that? As a user I would just call `key-pair list` and...

> Note that you point out the user-unfriendly step there: to perform a step, you first need to perform another one, ... This step is optional, it's only a helper...

### The problem I think that this is a very risky design on multiple layers and it needs deep consideration. First, there's the social layer. We're adding hidden communication with...

I propose a simple solution: The client should call `onchain_runtime_version` as the first thing after establishing a connection. The client knows, which versions it's compatible with. If the runtime version...

If a runtime version is known to the client, they're compatible, aren't they?

> it won't work whenever the runtime is at any newer version unknown to the client That's the whole point. If there's a need to bump the `spec_version`, it's a...

> we introduced a new validation spec for some tx, which changes nothing regarding its compatibility with the runtime. If it changes nothing regarding compatibility, we don't need a `spec_version`...

> For instance, #472 changes nothing to the client in terms of its compatibility It's not a good example. It changes the behavior and forces the client to change its...

> We are the only ones with a client of our runtime that we know, and our CLI is the only known client of our client that we can sensibly...