Ethan Frey

Check out https://github.com/cosmos/ibc/discussions/719

> The receiving chain must have the ability to execute "per-block" logic and write to the provable "ibc" store when a timeout for a packet has been reached. How can...

> If the packet is received after the timeout has been reached, rather than just aborting transaction; we write the absence receipt into the store and return. That is a...

> > This is true, and intentional. > > Also, may I ask the reason for this? This is a point for the spec in general - there is no...

Thank you for opening this issue, I think it will lead to a much deeper discussion on the fee issue. My first question is what is the desired behavior of...

My second comment is that it feels weird to jump into ibc-go implementation details here. Let us first discuss it on the level of spec and desired behavior. It should...

I would reiterate to have this as a spec-first design (no talk of ibc-go) and focus on desired properties like @colin-axner mentioned (where the fees go). My thoughts on minimal...

Also, I realize there is one fundamental issue with this design. While it seems to make sense to pay the relayer on the source chain for work on the receiving...

> The missing piece is incentivising relayer to pass receive packet. Which is actually the key point to incentivize in my mind. Otherwise, you just pay relayers to pass back...

Aditya, thank you for pointing this out: ```go MsgReceivePacket { packet Packet payToAddress string // this is the address of receivePacket relayer on source chain signer string // this is...