Christopher Goes

Difference between "UDP multicast" (no knowledge of receiver) and "receiver-known" broadcast. The former should not require handshakes, the latter will. Subscriptions mechanisms will likely require the latter (known receivers).

Maybe best for "IBC 1.1".

However, we should ensure that this can be added in a backwards-compatible way.

By the former, you mean "receiver-known" broadcast, right, since the sender designates the receiver set? Even with "receiver-known" broadcast I think we should allow the receiver set to change after...

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...

Generally I agree - however, I am not convinced that the IBC specification should include anything about governance, which in my view is an implementation detail of the Cosmos SDK...

> The Verify functions have side effects (clientState.consensusState.sequence++). This is not the case in the verify functions of ICS002. This is true, and intentional. Do you think this is a...

Approximately: - Polkadot: proxy clients on all parachains, main clients on relay chain of all parachains. - NEAR: trivial clients, almost like loop-back but asynchronous between block parts. - Eth...

Should these be blog posts? Documents in this repository? Ideally they would outlive specific protocol comparisons and instead serve as a more general reference, especially for future cross-chain staking topologies....

Also the proxy client topology, e.g. [this](https://medium.com/web3foundation/polkadots-messaging-scheme-b1ec560908b7).