@marbar3778 any updates on gaia release?

Awesome! Do you know if gaia will be updated with this new release or is it something I should request?

So far it looks like the nodes are keeping up with each other as I would expect.

I've deployed a patched gaiad - I'll report back in 12 hrs and see if the nodes are all keeping up with the chain as I would expect - it takes some time for them to fall out of sync since after a restart they all catch up to the chain head first before continuing other actions.

I’ll give it a try today. Apologies for the delay in responding.

On Mon, Aug 3, 2020 at 3:02 AM Erik Grinaker [email protected] wrote:

Hi @defunctzombie https://github.com/defunctzombie. Any chance you could try the fix out today? We're preparing to cut 0.33.7 as well, and would like to include this fix if we can get it confirmed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/tendermint/tendermint/issues/5112#issuecomment-667933570, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAUWOCYFOHMFCHCBAZKRH3R62DMNANCNFSM4OYBFOPA .

I'd say this request was to enhance that UX to make it editable similar to a full page.

What about a config option to disable?

I still don't think the retry logic as introduced in the bugfix is appropriate for how the Cosmos chain operates so being able to disable it would allow our nodes to stay updated with the chain.

@jleni Were in the app is this? I've installed v0.17.2 on a test device and clicked through the app's menus. I did not see any settings or screen to show the address.

A nice security enhancement is to display the Filecoin address on the device (rather than relying on a connected UI). This provides an additional verification around the user's account address.

Happy to clarify more if this post is not descriptive enough.

A backport would be 👍 since the bugfix that was applied to the v0.32 family is what caused the specific regression - so getting v0.32 back to a similar state for chain syncing would help operators with remote signers that are connected to several front nodes.

What's the best way to give #5140 a try? Change the go.mod file in gaia? Will the version of tendermint that change is based on work with the latest stable gaia?

I'd have a stronger preference for a config option to just disable the retry functionality altogether (ideally default no retry and allow folks who feel strongly that they need to tune retry to turn it on). I prefer simpler connection flow logic over pre-tuned retries especially on a fast moving chain.

Some thoughts on the earlier comments:

a) proposer might miss a chance to create a block and receive a reward

To me that seems like it is on the validator to ensure their connections are reliable to avoid missing the reward. The reward is also not that outsized that missing it as a proposer is significantly detrimental. Maybe the answer here is to have 1 immediate retry - if you failed that too then I still believe the right move is to move on.

b) validator might miss a chance to precommit for a block and get slashed for not signing

Missing one precommit won't get you slashed. If you are disconnected and come back online - the node would catch up and you would start signing current blocks which would prevent you from being slashed. You would need to be disconnected for ~16 hrs before liveliness slashing hits - if you are down that long - this retry logic would actually do more to negatively impact your ability to come back online and be at the head of the chain.

If you want to help folks avoid liveliness slashing - that should be done at a higher design/protocol level rather than per single block.

Absolutely - you know best what makes sense for the project. I wanted to provide the Dockerfile as an option since I had noted earlier that I would.

On the PR itself - something I've found helpful is to consolidate the config into a single file (config.js, env.js, etc) and use that in various locations rather than "window.env". It allows for a single place to document and simpler management of how the environment configuration is loaded (today from window, maybe tomorrow elsewhere) and avoid the window global sprinkled around the project files. Since you are already touching many of these locations now might be a nice time to make such a change.

Sorry I hadn't gotten around to making a PR for the referenced docker image PR - but if you wanted to keep your env vars during the build you can accomplish this using docker build ARGS as seen here:

https://github.com/Polychain/outline/blob/v0.43.3-pc0/Dockerfile

cc @melekes

We are running Cosmos gaiad 2.0.11 which uses v0.32.11 of the tendermint sdk. This version of the tendermint sdk introduced a bugfix via https://github.com/tendermint/tendermint/pull/4709/commits/100037877080bf73c951531732363451d51b5236 which is causing some of our nodes to fall behind in chain state.

We use the remote signing feature of a nodes to connect several nodes to a single backing validator (a scheme that has worked excellently for us since cosmoshub launch and we made available via our open-source validator here: https://gitlab.com/polychainlabs/tendermint-validator). With this approach the remote validator maintains a high water mark and will reject signatures requests for heights below the watermark. Prior to the change in https://github.com/tendermint/tendermint/pull/4709/commits/100037877080bf73c951531732363451d51b5236 our nodes would all keep up with the blockchain equally.

After the change - if a node happens to fall behind by 1 block (due to having lower block propagation time or network connectivity - it will continue to fall behind and fall out of sync with the chain and never catch up.

Given how fast new blocks are produced on the network - we see retrying as rarely useful and certainly not useful with such a long timeout.

My suggestion is to revert the commit and allow the next block to attempt a new signature and move forward.

@tommoor still interested in landing a version of this? I have some new changes to the approach (via using docker build args) that works more seamlessly with injecting env vars (for webpack) to the build process during the docker build.

Hi @defunctzombie, this module is heavily used by browserify and we'd like to do some updates (like bumping the resolve dependency). I understand you're not actively working on this package and I'd be happy to maintain it for the foreseeable future. Would you be open to transfering it to the @browserify org? Thanks!

I've transferred the repo to the browserify org and granted goto-bus-stop owner access to the browser-resolve package. Thank you for picking up maintenance of this module.

Sure - what do I need to do to make that happen?