Patch 3.2.0 ibc go to 4.6.0 - non-consensus breaking #431
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current vulnerability in IBC GO: GHSA-j496-crgh-34mx
Updating to v4.6.0 - non-consensus breaking.
Stargaze pushed this updated as a private patch before release. It was mentioned then it was non-consensus breaking and we could upgrade as soon as we saw the announcement.
I patched my version of the binary and have been running it on the IBC GO v4.6.0 today just fine. I am missing less blocks currently. I have made some changes recently to my timeout_propose that has drastically helped me to miss less blocks. Lowering that time has been beneficial.
But when receiving incoming IBC packets, my node would appear to 'hang'. It appeared that something was causing a 'timeout' or some delay after receiving an IBC packet and then going back to the consensus module. I don't know if there was difficulty in some way injecting the tx into the mempool or not. However, I am now seeing this happen far less.