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

Have you checked, what was changed in this specific release?

In your haste to create proposals, have you had time to ask for comments and explanations from L1 TF regarding this?

4 Likes

that appears to be the story… attack attack… participate… no thanks.

1 Like

Of course not. The plot & agenda of him and the group of people around him is clear as day.

1 Like

At this point, I honestly believe that if His Holiness The Pope farts, it’ll be viewed as an adverse reaction to JGs removal/withdrawal from the L1TF team.
This whole situation is now a joke and should not be viewed in any serious light.
Go in peace. But please go … and stay gone! Thank You!

2 Likes

My response to this prop is based on zero years of coding experience and complete lack of technical knowledge as it relates to this network upgrade. However I am certified in spotting Bull Shit props and this one has 10 Red Flags.

Nearly all of your arguments are completely unrelated to the code up grades. The majority of them have personal opinion bias, attacks on contributing members, and motive based on business facets that don’t favor certain parties within the community. Non of this prop speaks to any concrete, undeniable reason why we should not do the upgrade on a technical level or states .

Hard NO on this prop. It lacks supportive evidence of upgrade risk and majority of the contexts is politically motivated with numerous mentions of information that could be subjective and interpreted in differed ways base on a thesis that has nothing to do with the upgrade.

6 Likes

@StrathCole
Of course I’ve reviewed it. The concerns in specific are around the upgrade handler and the testing that has been done around it, like I’ve mentioned in this proposal. The conduct of the L1 JTF’s programming leadership (particularly Zaradar) has only added to my concerns around the integrity of this release, for the reasons I’ve listed above.

@Tonu_Magi
Here. You can see my posts as Nova Validator engaging with the L1 TF (particularly Ed) multiple times about the upgrade.

It’s worth noting that Ed’s response here only happened as a result of me following up with him in the Terra Classic Validator Discord, which you may not be a member of since it tends to be focused around validator specific duties.

Note also this post from Jacob Gadikian pointing out his concerns as well around the upgrade handler, which is a concern that has yet to be addressed as well. Updated v1.0.5 upgrade - #34 by faddat

@SockPuppet
@lunaticlunclover69
@EZMehrtenz
@Lunc_Global
Put aside any dislike you may currently have for how Jacob handled the Allnodes security risk situation.
Put aside any dislike you may have for me for putting up proposals that the community disagrees with because they’re unpopular opinions that are based on facts that can be tangibly pointed to.

I have a lot to lose as a validator if this upgrade handler blows up in a way we don’t expect. Every validator does. If we end up losing state on the chain because we didn’t do the proper testing and due diligence on this release as a group of validators, that’s a big problem that we can’t really easily come back from and we’ll have failed our delegators and we’ll have failed to secure the chain.

Postponing the release so everyone can take a closer look at it and give it the proper testing it deserves, and also giving ourselves time to sort through the fact that our chain is filled with compromised validators right now, is the responsible thing for every validator to be doing.

I honestly don’t see why this is even up for debate.

I think you don’t want to help.If the 1.0.5 update is delayed, the support decreases, there is no point in being a validator.
We have to stick to the roadmap. We can resolve this issue later. I think the prioritization is not correct.your approaches are starting to get boring.
We trust the L1 team. We don’t want to change. We don’t want an alternative L1 power. If these are not what you want, you can be a validator in another chain.We need the L2 team, contribute to the L1 team and improvements. Approaches such as do not develop, do not work are not correct.We don’t want another L1 team. You can leave if you want.

2 Likes

So you linked the convo with Ed and Ed said how they will handle it.

Then instead of proposing a better solution or inquiring further on the matter - you made a proposal that doesn’t offer a solution. Just asks for more time to investigate it.

I mean - isn’t your time better spent actually working on a PR to offer up?

I’m sure you have made many contributions so far, yes?

2 Likes

@Tonu_Magi
There is no part of that conversation that describes handling the issue at hand. You are getting your facts wrong yet again Don. Putting up a proposal to delay adoption of the release, investigate the codebase and take the time necessary to test it is the solution.

It’s called a “CancelUpgradeProposal” in Cosmos (read: x/upgrade | Cosmos SDK), but since our codebase is so out of date, we don’t have that as an option. So the next best thing is an Agora post.

I also don’t see why you feel the need to keep trying to question my contributions when there’s compromised validators that are refusing to remake their validators and validator wallets and an L1 JTF that is unilaterally merging in broken commits on a whim that other developers then have to play defence on. Those are things I’ve been handling that are bigger priorities and you know that because I’ve told you about that and shown you the proof of that as well.

This isn’t about me “helping out” by making pull requests. This is about testing and code review and verification of a release that has a potential risk to it if things are done wrong that can result in the loss of chain state. They’re entirely different things.

Also @tarikmandal I can tell you right now no sane validator should care about any L1 Team’s internal roadmap if it’s putting the chain at risk. Our job is to secure the chain. Not to ensure the L1 Team meets their roadmap.

This is development 101, guys.

If you read the convo between JG and Ed - you’ll see what was their solution to this.

So, unless you actually have alternative and viable solutions at the given time, with given tools - I suggest you let the L1 TF do their work, since that is what they are being paid for.

Now, as to your concern to compromised validators - how does this tie into 1.0.5 release? Is it relevant to 1.0.5? Or is it just another attempt at changing the subject.

Proposal isn’t about what PFC did or why Notional left or what Zaradar believes.
Yet you like to sprinkle in these tidbits as somehow pertaining to the code.

And as to the code - Ed said what he discovered and how they plan to overcome the issue.

Mayhaps be part of the solution for once?

2 Likes

Hello there,

This is basically why I left. I did not want to be pressured to approve of code that wasn’t good.

I I think that there are simply better ways to achieve the aims.

Don, Please link to the conversation between Jacob and Ed where they described a solution to the problem of upgrade handlers not accounting for real world chain state.

Read my reply to you again Don. I was addressing a point you made to me. You’re shifting arguments again while accusing me of being the one doing it.

Every point I’ve made is all part of a larger pattern that goes back months that leads to a very alarming situation to be in. Don, where there’s smoke, there’s a fire.

Please show me where you saw that.

This proposal is the solution that we have at this given time, with the given tools (your own words). You are just refusing to acknowledge that it is.

Your proposal lacks any form of a solution.

Who will be overseeing and approval of “proper” code?
Who will test it?
What will be the approximate timeframe?
What are the associated costs?

Drawing attention to a larger issue, while containing the proposal to one specific version upgrade?

Read Eds response. I’m on mobile. Hardly a welcoming environment for proper formating, but verbatim Ed said they will trigger it a specific block height (for 2.0.4) and that is their solution.

Now, as we discussed back in December - your team of Terra Allies was supposedly looking into Upgrade Handlers and you wanted to get a proper grasp on the subject. You and your team?

You identified an issue, waited after the proposal got passed, waited some more. Proposal is hastily written to stop and…?
What exactly are you solving by this? Who are you serving by this?

2 Likes

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