ICS3: Do we need a recency bound on consensus state in the connection handshake?

[cwgoes]

What if an old consensusHeight is used? Can this cause problems?

• e.g. if the timestamps of the two chains are off

Do we need to include verification of the unbonding period?

There should be a way for client types to say what needs to be verified in the connection handshake.

[adizere]

Relevant spec: ICS 003, in particular the opening handshake, ConnOpenTry and ConnOpenAck handlers.

[cwgoes]

The unbonding period is now verified. As far as I can think at the moment, an old consensusHeight isn't unsafe, although it might result in the light client potentially being un-updatable afterwards (if it just expires almost immediately).

A de facto bound will be imposed if a chain only keeps the last n of its own consensus states, maybe it's better to be explicit about this in the protocol logic and fail the handshake with a defined error code though. We can't really standardise on a particular n since we don't know the "speed" of the chains, but it can be user-configurable and the handshake can check.