Your justification is to attack a validator that will be dropped from the set!?!
Clearly, your reasoning is a joke and you can’t incontrovertibly make your case.
Most of your ideas are good, but those that aren’t, eg not actually burning OSMO but sending it to the qqqq address, are never walked-back by you. Check your ego, you’re not always right.
If the community feels really strongly about increasing the validator set, anyone can submit a gov prop to increase the validator set to 150 when this one passes. We shouldn’t think of these decisions as final these params are configurable for a reason.
I do think we should wait for improvements to the consensus engine before going any larger than 150 tho.
It’s great to see these discussions happening! 
It seems I’m in the minority thinking this propsal clearly infringes on minority interests, which is the definition of when to vote NO WITH VETO.
Kava cut their inflation to 0% a year ago, they have far fewer users than Osmosis, didn’t cut down the validator set, and everything is fine.
Eliminating competition means there’s more food for those left at the table. The largest validators would vote NO and it would fail, just as they’re voting yes now.
The reasoning behind this propsal is an absolute smoke screen, jingling the keys to get our attention while the largest validators mold the system to benefit themselves.
What a joke.
I understand your feelings, I think the community is proposing changes that benefit the chain in the long term, I do think that most validators vote for chain health and longevity.
What would be your ideal version of consensus set up?
I know I’m not always right, but I always aim to do what is best for Osmosis. I’m open to feedback on how to do better here.
What’s the issue with sending to the qqq address? It’s trackable, out of circulating supply, and requires 0 code changes.
This proposal has primarily become about consensus speed and examining how much that correlates with validator set size. The economic part of this came from a couple of feedback points during the last time there was a push to lower inflation. This proposal discussion has surfaced more feedback that validators consider this less important and are more willing to leave this to each validator to assess sustainability.
I’m open to feedback on how to do better here.
You are a powerful influencer, so many validators blindly vote “yes” to your proposals (as part of their virtue signalling of voting on all proposal, which is included in mintscan’s metrics for “good” validators).
Instead of barreling forward with promoting a forum proposal to an on-chain proposal without regard to enhancements/changes/suggestions to the forum proposal, it’d be good to effectively say “Ya, you’re right. I’ll add/make that change in an improved proposal.”. Case in point is the “burn address” versus true burn. The “there’s no code change” argument for using qqqqq was a terribly weak justification of your stance. The chain is made of code!
I don’t recall you ever pulling one of your proposals after forum protests. Correct me if I’m wrong.
I typically don’t pull proposals for two main reasons:
One proposal that didn’t go to the chain was Lend Community Pool USDC on Mars. I would still like to revisit this with a smaller amount, considering the feedback from you and LC, but it will need to be reworked.
Your comments have also prompted me to review previous proposals. I’ve had a few fail, and while they felt recent, the last one was actually 18 months ago regarding protorev distributions. Validators voting yes by default is an issue, but I don’t think it’s particularly because of me posting them but an overall bias.
I generally incorporate feedback during the discussion in the forums, but there often isn’t a substantial amount of input. Part of my role is to determine what seems reasonable during the drafting stage before it even gets to the forums so that could be one reason. Unfortunately, I cannot influence the prioritization of proposal action items that depend on code changes, so if we can focus on using existing governance mechanisms rather than requiring upgrades—at least in the short term—that is far faster to go into action even if the result isn’t perfect.
Agreed on this one. The problem is larger than the person posting the proposals on chain. As long as validators seem to run bots for their voting or vote without even knowing what they vote for… the problem will persist.
Something for which we sadly don’t have a solution for. Some big validators even have a “governance branch”, but they are rarely if ever seen on the forums. So it seems more show for customers than really bothering with the inner workings of governance imo.
Anyway, @in3s.com regarding the burn I agree with you. It does need a different thread though, since it is a different topic unrelated from the reduction of the validator set. Better to have clean discussions on the forum, to keep everyone aligned on the subject. Do you want to start a thread on that topic?
Do you want to start a thread on that topic?
No, now that we’ve been booted from the validator set we’re going to dump all our OSMO and be done with the chain. Good luck and best wishes.