Skip to content
This repository has been archived by the owner on Oct 4, 2019. It is now read-only.

ECIP-1015 - "EIP-150 fork implementation" #17

Closed
realcodywburns opened this issue Oct 14, 2016 · 8 comments
Closed

ECIP-1015 - "EIP-150 fork implementation" #17

realcodywburns opened this issue Oct 14, 2016 · 8 comments

Comments

@realcodywburns
Copy link
Contributor

In reference to:
ethereum/eip150

Concerning: Long-term gas cost changes for IO-heavy operations to mitigate transaction spam attacks

With the understanding that:

  1. This is a fork intended for protocol improvement.
  2. This is mutually beneficial to all etherem clients in order to mitigate current attacks.
  3. Ethcore and Ethereum Foundation intend to implement the changes in unison on or around block 2,463,000
  4. an unknown number of ETC nodes are using --oppose-dao clients and will be switched to the EIP gas price model at block 2,463,000

Issues to address:

  1. The need to avoid silverware drawer of ethereums:

a. EF Official
b. EF Official- no eip 150 fork
c. EF TheDao Classic (accepted 1920k but ignored GasReprice, not upgraded nodes basically)
d. ETC Early GasReprice, block 2,463,000 (uses upgraded EF version of geth with --oppose-dao flag)
e. ETC Late GasReprice, block 2500000 (uses etc version 2.0.0 client)
f. Ethereum Classic Classic (doomed) no forks ever from homestead

  1. Urgency - this needs to be ready for testing as soon as humanly possible.

  2. MAKE THE PLAN KNOWN. on all channels. smoke signals as need be.

Proposed actions:
0. MAKE KNOWN TO EVERYONE WHAT THE DECISION IS AND PUBLISH REQUIRED CHANGES IN ACCEPTED ECIP.

  1. Incorporate EIP-150 as ECIP-1015, to follow our process
  2. Attempt to reach agreement with EF devs to either support etc flag forking on 2,500,000, or disable –oppose-dao-fork switch completely (absent that, an active campaign to get people to upgrade to classic geth)
  3. Get parity buy-in to make a new release supporting our HF (which would require a PR be submited for json config change)
  4. Implement ECIP-1015 on top of our 2.0.0 geth code base, test it
  5. Release new classic geth version, promote its usage heavily among ETC users, as well as with pools, exchanges, and wallets that support ETC
  6. Hard fork on block 2,500,000 ~2016-10-25
@arvicco
Copy link
Contributor

arvicco commented Oct 15, 2016

A simple course of actions recommended for ETC geth users:

  1. Use classic geth release (http://github.com/ethereumproject/go-ethereum/releases)
  2. Upgrade to the latest classic geth release available at the above link shortly before planned hard fork date (2016-10-25)

@realcodywburns
Copy link
Contributor Author

Parity has released their eip150 update today. They have left the classic chain with the option to impliment the changes at a block of out choosing. Gavin submitted a PR for block 2,500,000 so that it can be rapidly adopted as needed.

https://github.com/ethcore/parity/pull/2636

@realcodywburns
Copy link
Contributor Author

ETH geth changes for review:
ethereum/go-ethereum@c72f545
@whatisgravity @splix @avtarsehra @ericsomdahl @elaineo @igetgames @mikeyb

@marcusrbrown
Copy link
Contributor

It appears that two new attacks have surfaced on ETC (via replay most likely) and ETH that focuses on the EXP and BALANCE opcodes:

Opcode Contract Description
EXP ETH / ETC Increased CPU load
BALANCE ETH / ETC Forces disk access for state not held in cache

If you look a the VMTrace (GETH) on Etherscan for each, you can see that the damage is done before the contract runs OOG.

I know we are pressed for time before the gas reprice HF, however, I at least wanted to discuss to see if it's possible to reprice these opcodes and test them by the 25th. If not, then we need to come up with another strategy. Thoughts?

I am working to get cpp-ethereum ready for 2500000 (60% likely I can finish, but it will need review) and the tests merged to a point where we can use the central tests repository (as cpp-ethereum does with testeth, the test runner).

@arvicco
Copy link
Contributor

arvicco commented Oct 19, 2016

Well, we delayed our HF timing in part to see what else attacker may come up with that we could counter-act, right?

@marcusrbrown
Copy link
Contributor

Yeah, so first off I want to apologize to the community for being so agitated last week and pushing for a simul-fork, waiting a week looks to be the right choice and approach.

Ideally we would do a full EVM opcode survey, Nick Johnson has said they have, but if it's public I haven't tracked it down yet. I will do a quick scan on the Yellow Paper, but it's still all guesswork.

@realcodywburns
Copy link
Contributor Author

Moving to #19

@realcodywburns
Copy link
Contributor Author

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants