Aditya

How would this work with the current ibc-go implementation where the type is a uint64 at the moment?

Ahh yes you're right. Sorry wrote this up with just an initial sketch of an idea. Of course, the receiver chain cannot know the timeout of a packet which it...

Yes, we actually already do this. ORDERED timeouts already work without absence proofs So the above proposal is only relevant for UNORDERED channels

Yes this is non-breaking from a protocol point of view since it's just an additional feature. One thing to note, is that I believe currently a relayer will not recv...

Great questions @damiannolan Yes, it is intended that packets in-flight are "paused" until the upgrade is complete. This is to ensure that packet flow cannot happen while the channel is...

> If I'm reading this correctly, counterparties would need to upgrade first to be able to read the new information. Once counterparties have completed their upgrade, they're able to receive...

I have a rough sketch for a general idea that I want to pitch here before writing it up into a broader spec. I propose we still keep the notion...

Thank you all for the feedback. Definitely this should be written out as a spec. I've written it up in SDK terms just to demonstrate the general point, it's also...

> how does refunding work? This is up to ibc-fee handler and could vary from chain-to-chain. A default implementation would be that the sum total of fees get escrowed on...

> To step back a little, it does seem like doing all fee payments on a single chain is the ideal option, but in the general form of this problem,...