Overwrites and ignorances of pre-existing features during the implementation of Atlantis

[GregTheGreek]

In light of #66 #67 there was a communication breakdown of a few ETC specific forks that occurred. @YazzyYaz pointed me to a couple things we should double check.

• Difficulty bomb removal :: [Here] (https://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1041.md) - this should fix core/block_validator.go#calcDifficultyAtlantis: should not use hardcoded bomb delay #66 / core/block_validator.go#calcDifficultyAtlantis is wrong #67
• Supply Cap :: Here
• IO/Gas Model :: Here

[soc1c]

what's the difference between #66 and #67 and isn't supply cap already implemented and activated? could we have one ticket for each issue with discover? this would be a mess otherwise.

[GregTheGreek]

supply cap should be implemented, but I want to double check, never know what you'll find.

I think everything is implemented. IF anyone discovers they're not correctly done we can break it out.

[meowsbits]

Indeed,

• Supply cap (aka Disinflationary Monetary Policy, ECIP1017) is already implemented (via hard fork approaching two years ago).
• IO/Gas model (EIP150) countering network spam is also implemented via hard fork even before that.

As I see it, the important idea of this issue is to flag potential 'overwrites' or ignorances of these pre-existing features during the implementation of the next fork (Atlantis) features, as was the case with #67.

Hotspots with this might include

• difficulty calculations (given already implemented difficulty bomb disposal w/r/t EIP100
• rewards (given disinflationary model) w/r/t block reward adjustment that was implemented coincidentally with difficulty bomb delay in byzantium
• state trie clearing (EIP161) implementation; aspects of support for this feature have been partially implemented, although sometimes unfortunately hardcoded (eg statedb.IntermediateRoot(false)). This is a tricky one because it is unclear exactly how partially or wholly this feature was already partially implemented. Not pretty, mostly edge case relevant, lots of tendrils.

Medium spots:

• EIP658 tx receipt status encoding; this was preexistingly partially implemented for storage, but not for consensus. afair features were in place to satisfy the eth API specs for ETH interoperability on-the-fly, w/o extending support through wire protocol. are there adequate unit tests for these new RLP encoding/decoding cases?
• evm handling around new opcodes behavior

Cold spots I would expect (places which can be relatively satisfactorily unit-testable and/or comprehensively integration testable):

• precompiled contracts' unit logic
• new opcodes unit logic

[GregTheGreek]

@meowsbits thanks for this beautifully written comment, I think its worth breaking that into its own issue(s) - I'll get to that tomorrow