Network Security Proposal - Cancel and Revert Validator Upgrades to v1.0.5

oh man,

good point, good explanation.They never end, they’re like fud robots.
they are very tiring. Sometimes I think maybe I should sell everything and get rid of it.I would not want to be a developer on this project.
There’s a community that keeps blaming.

‘‘If You’re Not Part of the Solution, You’re Part of the Problem’’

1 Like

Pausing and taking a deeper look is the solution.

Validators and professionals in the community, as has always been the case. It’s our responsibility as validators to do so. If people would stop hating on the idea of an alternative L1 Team we could pay Notional (or other Cosmos developers in the space) to also give a second opinion.

I can’t speak to timeframe because we don’t know what we don’t know yet. A continuation of resolution of the issue would have to come in a later proposal after more discovery has been done. As for costs, that would depend on quotes we get from other L1 Teams we engage with to help provide a second set of eyes on the testing aspect of the release, particularly with a focus on the upgrade handlers and how it’s interplaying the current 7TB of chain state that we have. It’s a pretty complicated problem, that deserves the proper attention.

I’m telling you that doesn’t solve it from a testing standpoint. You’re misunderstanding the problem and thinking that Ed’s block height solution solves it, which it doesn’t. Delaying the upgrade handler trigger to be after a certain block height doesn’t solve the problem if the testing around the upgrade handler itself has been inadequate. It just creates a ticking time bomb that may blow up later once we cross the block height guard instead of as soon as validators upgrade their nodes. Not a risk worth taking without us looking closer. We can’t just run code like this on blind faith now that concerns have been raised, it’s irresponsible.

Yep, and we did. And we have. And we have a much stronger understanding of Cosmos now then we did back then. In another month our understanding will be even stronger then it is now.

Everything that ultimately made me change my view on the integrity of the release has happened in the past couple days, and is not a view I came to lightly. That’s why you’re seeing me speak up about it now.

Avoiding the risk of potentially breaking the chain and it’s smart contract state.

My delegators. Other validators. Their delegators. People who aren’t even delegating and just have funds on the chain or engage with smart contracts. You.

1 Like

Bilbo, as it is with any proposal - let’s have the governance decide.

We will keep going in circles and the outcome is predictable.

But as I did say to JG, keep in mind how the validators and Allnodes - the compromised ones - have been around since start of TC. More or less.
While it’s great the issue has been identified now, 10 months later, it doesn’t exactly spell out a reason to stop all life for undetermined time.
Unless you imply that Allnodes wants to tank their business and turn malicious?

Certainly, vals and Allnodes need to rework their shoddy system, but it’s not exactly cause to stop all development.
This is the idea of your proposal, no? To stop development until chain is not compromised?

And while Zaradar and ionman (not sure who that is or if spelled correct) certainly have had a tug of war over piece of code that has no effect until we remove 4.8 trillion Lunc - it does not also seem a imminent threat.
While micromanaging a small team through governance might seem fun - I would let them grow and learn their own path, if they are to continue and not bow out when egos clash. JG didn’t want to approve of broken code and left. Ionman(?) simply removed it and kept on doing the work.

I suggest you be a candidate Q2 L1 TF. Then you can stop all these wrongdoings live, in action and god forbid we have some proposals against you or your practices. It’s becoming a joke.

Good luck on the votes!

2 Likes

Hello friend. I’m all for being cautious and checking stuff thoroughly, a few things to consider if I may:

  1. I thought the constrained pool idea was merged into the next release not this one.

  2. re the missing data I think Ed has responded re the same on discord. Is that sufficient for you.

  3. this post has been up for a few days, have you located any frailties in the code that would indicate issue? Note we have I think perhaps ten days to identify potential issues.

  4. I have seen JG post today about an issue, which he subsequently deleted. Any idea what this is in relation to and if so is it something to raise in discord?

I appreciate JG was trying to discuss a real issue with Allnodes but his handling has resulted in a lot of scepticism when he makes statements. So would be grand if you could consider point 4) with your fellow validators in private (wouldn’t want an exploit to be publicly broadcast) and come to consensus as to the depth of the issue.

Regardless of how this ends up I appreciate your effort, diligence and hard work sir, keep it up!

1 Like

Okay, so you are reading it like a height gated upgrade handler. Got it. Yeah that’s highly nonstandard but…

Would you mind linking the code?

Like the exact place where it’s triggering you. I know where it triggers me but I want to see if the same place for you and I also want to say the thing is I just don’t know if it will work but when we ship this stuff we should know

You lost any professionalism and credibility in this proposal, when you started attacking members of the L1TF. It makes you look envious to me. If you don’t like it, see problems in it, help with a technical solution, rather than trying to stand on others fingers. A very emotive and unprofessional proposal and a No from me.

1 Like