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.
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.
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.