I suggest people come up with reasons as to why they believe we should choose a specific block. We need to provide arguments if we want to come to a conclusion and this can only be done if we all list the pros/cons and explain why these matter for ETC network. We should always make decisions that prioritize network stability/security because some errors can cause huge damage to the ETC network and consequently its stakeholders.
Answers like I don't want to fork at block 'X' or we already agreed on the date are IMO invalid. The reason being is:

1. the "Asian miner/exchange community" assumption from which the date was set appears to have been incorrect
2. a new Atlantis client appeared out of thin air and was not taken into account when choosing the date the first time

We can learn a couple of things from this:

1. we should communicate more openly about what the intents of the parties are
2. we need to share information regarding clients openly and the code should be open source and available to read instead of dropped at the community in the last moment

Lets openly state if there is work done that it touching the ETC network. Software estimation is hard as is, such information needs to be public in order for people to give a valid estimate.

So please, come up with rational arguments. Everything else will be discarded.
We should optimize for 2 things. Keep ETC decentralized and avoid a network split. If any of these two fails, ETC loses its core value.

In my case, I continue to support the motion that the block should be moved back to 8,750,000 because:

• The previous agreement on block 8,500,000 was not considering that Classic Geth was going to be available for Atlantis.
• Classic Geth has to be available because many stakeholders will not migrate to Multi-Geth or Parity.
• Classic Geth was published very recently and core devs say that 3-4 more weeks are necessary for proper testing.

The decision of on which block the hard fork should be done, should be based first on the results of the tests, if for us the security of the network is important (If they will come towards, that we can do it on block 8.75, then it is fine). At the second step, we should check, whether ALL the participants are ready for it. And only then the hard fork should be executed. The Classic Geth tests are included.

Just for the record, this was the proposal from the last call that was almost accepted:

1. Testing on Kensington (block 100), Kotti (block 716_617), Morden (block 4_729_274) continues as agreed upon in the previous call.
2. We commit to a testing deadline roughly around July 28th, 2019 which we use to evaluate the status and maturity of Atlantis.
3. If there are no major problems discovered in that testing period, we commit to activating Atlantis on mainnet with a target in September around block 8_750_000.

We can use this as the starting point of the discussion (maybe).

Is the a list of functional and nonfunctional testing protocol that the networks are looking to pass prior to go live, or is the only criteria that the nodes dont have noticable consensus failures when just syncing on a test net

Just to make sure the upgrade does not hit a weekend, here are some numbers for discussion:

• "Potential Atlantis upgrade target for block 8732000 would happen around 2019-09-10 12:00:00 UTC based on current block number 8251958 at 14.96 seconds block time."
• "Potential Atlantis upgrade target for block 8743000 would happen around 2019-09-12 12:00:00 UTC based on current block number 8251958 at 14.96 seconds block time."
• "Potential Atlantis upgrade target for block 8772000 would happen around 2019-09-17 12:00:00 UTC based on current block number 8251958 at 14.96 seconds block time."

(Trying to avoid a fork on 9-11 lol)

I'm unfortunately going to miss the call tomorrow; I'll be ✈️ .

As an anticipated absentee, here's my two cents:

• I'm OK with any target hardfork number that gets decided.
• I would advocate continued work, with open and collaborative relationships, across client teams to build together criteria and strategies and delegated responsibilities for both test-network and x-client integration-testing strategies and goals. I've just opened this issue as a potential space for this: discussion: x-client fork prep and test patterns  #84

Hey everyone, I'm currently not sure whether I will be able to join tomorrow's meeting. So just want to post some of my comments. First of all, congratulations everyone! From what I know ETCLabs finally turned back and agreed to push the hard fork date back to September. Thanks all community members who have defended the integrity and security of Ethereum Classic.

To re-hash issues why we definitely cannot hard fork in August:

• There were 2 consensus bugs discovered in Classic Geth recently (Transactions causes split with Parity eth-classic/go-ethereum#55 core/block_validator.go#calcDifficultyAtlantis is wrong eth-classic/go-ethereum#67). Both of them are serious issues which, if undiscovered, will cause a consensus split. This shows that the Classic Geth codebase is not yet matured for production usage. As a result, we need to have at least an extra month or more for the extended testing period. Considering that we need an additional 6 weeks after testing period to inform miners/exchanges/nodes, this puts the earliest possible hard fork date back to September.
• As much as we like Kensington, the testnet is not enough. In particular, one feature added this time is EIP-161, which operates on empty accounts. However, the transition period for Kensington is too early that there is never an empty account on chain. As a result, EIP-161 remains untested no matter what we do on Kensington, and we need another testnet to make sure everything works. This requires extra time.
• We also need to plan for additional code reviews and also importantly, fuzzy testing. All of this take time.

Regarding @soc1c's comments on predicting the hard fork date: the issue is that we cannot. ETC has only around 1/10 of ETH's hashrate, which means because we're sharing the same algorithm, total network hashrate can fluctuate a lot. This makes the actual time unpredictable. Especially during hard fork, miners may have incentive to switch chains to take advantage of the fork. This is something that has happened in the past. So picking block numbers based on prediction of whether it's on weekdays or weekends probably does not make much sense.

Regarding the block number -- anything in September should be fine. A slight consideration is that we may have some members in the community who just do not want to hard fork before 8.75m, either due to politics, philosophy or practical planning issues. So it's best to pick the block number to be on or after 8.75m. That is, choose from 8750000, 8772000, etc.

Good luck everyone tomorrow! And congratulations!

ECIP-1054 was accepted with the mainnet upgrade target of 8_772_000. 👍

Good work!