[PROPOSAL][ABANDONED] Cosmos Hub 3 Upgrade Proposal C (abandoned)
Edit: Abandoned for Proposal D in favour of a new block height: [PROPOSAL #16][ACCEPTED] Cosmos Hub 3 Upgrade Proposal D - #2 by Gavin Looking for feedback on this: accounts.google.com Google Docs: Sign-in Access Google Docs with a personal Google account or Google Workspace account (for business use). This proposal is intended to supersede Cosmos Hub 3 Upgrade Proposal B , which we have deemed to be flawed. 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. Instructions for migration: Cosmos Hub 2 Upgrade · cosmos/gaia Wiki · GitHub Decision We are signalling that: •…
Excerpt (1197 of 1703 characters). Read the whole post on the forum ↗
Also looking for RTs for visibility: https://twitter.com/Ether_Gavin/status/1166820073107075074
Gavin:Genesis time will be 120 minutes after the UTC timestamp of Block Height 1823000
Is there a procedure for obtaining the UTC timestamp and is this documented in the linked upgrade process?
Will there be a fallback plan if the chain fails to start?
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.
I agree. I will revise this 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’ve requested that @bez add this recovery plan and instructions for obtaining the target export block timestamp for validators: https://github.com/cosmos/gaia/issues/116
@roman, thank you for bringing attention to these items.
Updated the upgrade instructions with a section on recovery and how to get a block’s canonical UTC timestamp. Feedback welcome!
Proposal 15 is live and in the ‘deposit period’: https://hubble.figment.network/cosmos/chains/cosmoshub-2/governance/proposals/15
Spread the word!
Gavin (Ether_Gavin)
Proposal 15 didn’t exit the deposit period before September first.
Now the earliest the vote period on Proposal 15 will end is September 16th which will be after the proposed block upgrade.
It seems like either we won’t wait the full voting period and treat a majority vote before Sept 15th as binding or a new proposal will be required.
Are there any concerns with considering it as a majority vote?
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.
Appreciate the feedback–thanks for engaging 
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 
Back to the drawing board for an appropriate day/time: Cosmos Hub 3 Upgrade Proposal D