This proposal is intended to signal acceptance/rejection of the precise software release that will contain the changes to be included in the Cosmos Hub 3 upgrade. A high overview of these changes was successfully approved by the voters signalling via Cosmos Hub 3 Upgrade Proposal A.
We are proposing to use this code Release v2.0.0 Ā· cosmos/gaia Ā· GitHub to upgrade the Cosmos Hub. We are proposing to export the ledgerās state at Block Height 1823000, which we expect to occur on Sunday, September 15, 2019 at or around 2:00 pm UTC. We are proposing to launch Cosmos Hub 3 at 60 minutes after Block Height 1823000.
We are prepared to upgrade the Cosmos Hub to cosmoshub-3 based upon
a) Commit hash: 3c70fee433956ba32e35705193a5f7a7d5b63277;
b) The state export from cosmoshub-2: Block Height 1823000;
c) Genesis time: 60 minutes after the timestamp of Block Height 1823000.
Feedback on the proposal as a whole - I think it would be best to avoid amending an existing in-flight proposal (since it has not passed) and simply provide a new proposal that specifies the entire upgrade process as desired. Abandon the existing proposal.
Proposed recovery scenario in case the chain fails to start.
In the event that a validator determines that the cosmoshub-3 chain is unlikely to start,oor if target upgrade block time + 6 hours has elapsed without block generation, validators MUST resume signing on cosmoshub-2. During the upgrade process, Validator MUST preserve a snapshot of node state on the target block height to preserve recovery of their validator and sentry nodes to the cosmoshub-2 chain.
Governance procedures on the cosmoshub-2 chain will be used determine a future course of action for the network.
Figment will vote ānoā on Proposal 14, and my intention is to push a new governance proposal that supersedes Proposal 14. Please note that I have edited this post with the new draft proposal.
I donāt like this. I already dislike that we did it for proposal #5, but at least for that it was agreed upon in proposal #3. I donāt like the idea of breaking the on-chain governance procedures for something as important as coordinating a hard fork especially when it doesnāt seem that time urgent (like proposal #8 was).
I think we should just make a new proposal, preferably one whose hard fork block is based as a delta from the block number in which the proposal ends.
If this concern is the 120 ATOMs that have already been deposited, I plan on making a proposal that deposited atoms on proposals that donāt make it to voting period should be refunded. And if that passes, some community pool proposals to refund the people whoāve already been affected by that. Iāve just been waiting for this hard fork to be over to make that proposal
Oh, also, I donāt like that thereās 0 time between knowing whether the hard fork is happening, and it actually happening. Everyone could be prepared to fork, and then suddenly someone decides to change their vote and it swings the result. Would be a shitshow.
Yes, I see no reason we should have to use a majority vote in this case, given the lack of time sensitivity. I suppose itās time to draft Proposal D with sufficient timing between the governance phases.
I was also planning to make a proposal to refund deposited atomsāwant to collaborate?
Re: block height relative to proposal ending, that could put us into some weird hour of the night on some untimely day, and Iām trying to avoid things like large holidays, daylight savings changes, etc.
Well itās a good learning experience! My goal is to get validators more engaged in the draft part of the proposal so that we donāt end up with Proposal W
