Final Call: ECIP-1054 Atlantis Upgrade

[soc1c]

ref etclabscore/ECIPs#25

ETC Core Devs Call - Atlantis Finalization

When: Thursday, June 13, 2019, 3pm UTC, 60 minutes max.

Where: Ethereum Classic Discord #ecips channel. Will use/create a voice channel ad hoc. Ask for invite here if you are not on that discord.

Agenda

• Quick client teams check-in
  • Geth / Multi-Geth
  • Parity Ethereum
  • IOHK Mantis
• Testing updates
  • Kensington Testnet
  • Kotti Testnet
  • Morden Testnet
• Atlantis (ECIP-1054) is in "last call" state
  • ECIP-1054 needs to be either accepted or updated (or rejected)
  • ideally, we agree on how (and when) we accept Atlantis in this call

[TheEnthusiasticAs]

Q to EIP161:
What will happen if someone, who created an address X years ago, which wasn’t used a long time, and now after implenting EIP161, there will be a transfer to it? I assume that one will be rejected!? Are then his/her ETC got lost?

Thx for the answers.

[phyro]

I'm copying over the answer from @pyskell :

My opposition is the following:

1. These rules can simply be applied to transaction validation rather than block validation, making it a soft fork rather than a hard fork.

2. In practical terms this will make no difference, miners will download one of the clients that has these types of transactions excluded by default and future blocks will not contain any such transactions.
3. It's vitally important to stick to pre-agreed rules when they're defined. In this case gas limit is a rule that governs computational size of transactions and there was no bound on physical data/contract size.
4. There's precedent for these types of things in other cryptocurrencies, example: bitcoin/bitcoin@6a4c196
5. Whether this is a contract creation call or an internal contract call shouldn't matter, both types of transactions can simply be rejected from inclusion in a block if their data is greater than maxCodeSize (per geth's implementation). As per point 2 I believe most clients will update and enforce the soft fork.

Regardless I don't want to delay the Atlantis hard fork and apologize for the late comment.

What are your thoughts regarding this?
As I mentioned in the previous thread, I'm still slightly more in favor for a hard cap, but we could try the soft fork solution to see if it catches on and we could do a hard cap later on if needed. Assuming @pyskell solution has no attack vectors and that the miners do adopt it, how much harder does this make it for devs?

cc: @tzdybal @meowsbits @shanejonas @BelfordZ ,...

[zmitton]

Thank you for deciding to rescheduling the meeting. Its now clear that was the right choice.
Thoughts on EIP 170:

First, unfortunately we cannot really solve this so easily with @pyskell's proposed soft fork. The problem is that some transactions can result in the creation of a contract (when a function call does a CREATE operation). This can happen at any point during execution (for example at the very end of a large amount of computation). In such a case, it would break the ethics of our gas-mechanism to simple throw away the transaction without charging the sender. If we charge the sender, it's a hard-fork (because it's a new, previously invalid, on-chain behavior). (description of a similar issue)

My second observation is that the real problem is not CREATEing, but CALLing. Calling apparently costs only (originally 40) now 700 gas (according to yellow paper update from oct 2016)

The constant gas cost does not properly reflect the variable required work of loading a contract from disk to memory
Here is a more direct proposal that came after EIP-170: ethereum/EIPs#1662
It simply makes the gas-cost of loading the contract dependent on size, by caching the size data in a new field on the account. Actually I'm wondering if the caching is even necessary (should be able to just load the contract and determine size at that point?). I'll bring it up in that thread.

There is at least 1 way to achieve mitigation of the attack vector as a soft. One roundabout way would be to simply set the block-gas-limit to a lower amount like 1 or 2 million. This can be hardcoded (as a soft fork), or even be done simple by having all client developers change the default setting, and asking miners and mining pools to use that number. Many of us have advocated this on other grounds

Conclusion:

Although there are more direct and/or less authoritative ways to fix this issue, I support moving forward with EIP-170 in its current form. I don't believe there are any significant mutability concerns with EIP-170

The current code architecture (using a fork of geth) I think is the most reasonable option for ETC given our limited developers and resources. Nearly all client devs have said the tests are easier to run if we keep everything eth-compatible (for now). We only have a handful of client devs supposedly attempting to support 4(?) client implementations. Compare that to ethereum's 100+ devs contributing to Geth alone. I think that's a huge problem but I digress.

Under this architecture, EIP-170 is the least complex solution. It also keeps us on track with the greater Atlantis ECIP.

[meowsbits]

@TheEnthusiasticAs

I assume that one will be rejected!? Are then his/her ETC got lost?

No, the transaction will not be rejected and the value will not be lost. The transaction will operate normally.

[soc1c]

Closing in favour of #80

[soc1c]

Reopening after #80

[soc1c]

starting on time in 15 minutes on discord https://discord.gg/HJfne6e

join the meeting audio channel

[soc1c]

Rough outcome:

1. everyone agreed ECIP-1054 should move forward as proposed, as a bundle of proposals; no included proposal was objected; on a technical level this is accepted now
2. the timeline of testing and mainnet-hardfork activation was contested and no consensus was found
3. a subsequent call will be held 7 days after this meeting, hopefully to further discuss the client landscape, review / testing results, and potentially a timeline everyone can agree upon

[soc1c]

k