Timeouts on ORDERED Channels shouldn't work

[AdityaSripal]

Must VerifyNextSequenceRecv instead of packet receipts for ORDERED channels

[colin-axner]

is this still true?

cc @seantking

[jackzampolin]

Is this still true @colin-axner @seantking @AdityaSripal ?

[AdityaSripal]

Looks like it: https://github.com/cosmos/relayer/blob/master/relayer/relayPackets.go#L41

It should be querying next sequence recv in case of ordered channel

[jtieri]

Is this still applicable? With the recent refactors to the relayer to move everything behind the provider interface this could would now exists in lens

[colin-axner]

I'm guessing so, as @AdityaSripal says:

Must VerifyNextSequenceRecv instead of packet receipts for ORDERED channels

Timeouts on order channels require proofs of NextSequenceRecv
Timeouts on unordered channels require non existence proofs of packet receipt.

The function linked above works for unordered channels. You need different functionality for ordered channels

[colin-axner]

You can probably test with interchain accounts once beta1 is out. Beta1 will allow interchain accounts to have a timeout value specified by the user (currently set to a constant that is never reached). Interchain accounts uses ordered channels

[AdityaSripal]

Seems like the msgRelayTimeout still only queries packet receipt. Instead it should be querying packet receipts for UNORDERED channels, and NextSequenceRecv for ORDERED channels.

https://github.com/strangelove-ventures/lens/blob/dc50c1d0d3b61614f09d125d8ae931f306625057/client/relayer_packets.go#L44