@MicahZoltu does have a point, this EIP is less of a specification and more of an informational memo. For that reason, I think it would be best to categorize it as such, rather than under the Standards Track. However, I think that modifying the ether issuance schedule is an appropriate change to EIP under the Standards Track. I also think that the deposit contract is EIP-able due to it's role in the genesis of a new, ether-issuing chain.

@MicahZoltu,

The EIPs repository is for technical specifications, not end-user support/educational material.

That's not strictly true. EIPs can be of type Informational, where an informational EIP "Describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community..."

Trying to have only a small portion of the spec in the EIPs repository (which is likely to end up out of sync with reality if not maintained as the canonical source of information) is likely to lead to a maintenance nightmare

I'm not sure this necessarily follows. It depends on how stable the included portion is expected to be, the language used to clarify future uncertainty, amongst other things.

If the specification lives elsewhere, why bother with an EIP?

The primary purpose of this EIP isn't to mirror the spec. There's information contained in this document that is not included in the specification (and vice-versa). Symbolism is important. It would be quite strange to have no mention of Serenity (perhaps the most significant improvement to ethereum) in a repository devoted to keeping track of improvements to ethereum.

From EIP-1:

EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.

"Ethereum Improvement Proposal" <-- this is precisely what this is. There is a (large) specification maintained in a separate repo and this is a concise proposal on how to use that specification to improve Ethereum (i.e. to reason about the motivation, to provide a reference to the "canonical" spec, and to commit to this as part of the roadmap).

This EIP is also a tool for "building consensus within the community" as a place to point to canonical-ness of a single deposit contract and release of the specs, as well as a singular place to discuss the ultimate acceptance and integration of the phased eth2 as part of the protocol.

I actually would argue this EIP is "Core" because it is designed to expand the consideration of what the Ethereum "layer 1" protocol is to include the PoS beacon chain, and is a commitment to a series of breaking changes (most prominently the swap of Ethereum's PoW consensus for that of the beacon chain).

I also expect much of the stateless ethereum work to manifest as similarly structured EIPs -- a concise motivation and reference to a larger spec -- because these specs, too, are also being designed in an independent spec repo

In terms of classification, I can definitely see how this EIP can be considered Informational. A working system could not be generated from it, requiring specifications described and maintained elsewhere outside of the EIP process. Should this be a requirement of a Core EIP?

I actually would argue this EIP is "Core" because it is designed to expand the consideration of what the Ethereum "layer 1" protocol is to include the PoS beacon chain, and is a commitment to a series of breaking changes (most prominently the swap of Ethereum's PoW consensus for that of the beacon chain).

In terms of intent, this EIP can be considered a Core EIP. It follows a long history of precedent of Core EIPs modifying the protocol. While EIP-2982 does not yet modify the current system, it is clearly intending to be an upgrade to the network in later phases over the long term. How else would Eth2 protocol researchers and developers propose these kinds of important changes to the protocol?

I also expect much of the stateless ethereum work to manifest as similarly structured EIPs -- a concise motivation and reference to a larger spec -- because these specs, too, are also being designed in an independent spec repo

Editors, how difficult would it be to submit the full contents of another repo in order to best represent the full system that is proposed? Should it all be packed into one file when being submitted as an EIP? This becomes more and more important as Eth1 becomes upgraded by large system-wide changes and additions of new systems.

This is not yet an actionable proposal to change the Ethereum protocol, so it's not a Core EIP. If it were an Informational EIP I'd have no objections.

This is "informational" in that it is informing the community of the particular specification and deposit contract to be used to bootstrap the beacon chain consensus.

This is "core" in that the vast majority of the community sees the bootstrapping of the beacon chain as an extension of the core protocol, and plans for it to drive Ethereum's consensus (superseding PoW) in the relative near-term.

I don't particularly care where this falls between the two, but this EIP will lead to followup "core" EIPs sooner rather than later as the beacon chain solidifies and the community is ready for it to drive consensus.

This is "core" in that the vast majority of the community sees the bootstrapping of the beacon chain as an extension of the core protocol, and plans for it to drive Ethereum's consensus (superseding PoW) in the relative near-term.

All that seems to be needed from the mainchain for Phase 0 is the ability to run the Validator Contract. No changes to the existing protocol are required, so no Core EIP is required. Specifications for how the Beacon Chain can replace PoW would of course need to be Core EIPs.

I also share Micah's concern that this EIP risks being outdated by the more detailed specs it references. A less detailed Informational EIP could be more easily maintained in that respect, and perhaps be more accessible and useful for the wider community.

@MicahZoltu @djrtwo Are you satisfied that this is ready to merge? I am. (Or at least I think I am - Github doesn't make it entirely clear to me that all my suggestions were resolved, but they appear to be.)

I'm against Informational EIPs so consider me abstained for the purpose of merging or not. My fight against Informational EIPs isn't appropriate on individual EIPs, so at the moment my policy is to just not merge them, but also not block them (since at the moment they are a valid EIP).

@MicahZoltu Although github will let me merge this for some reason it would be cleaner if you and @djrtwo resolve he changes you requested in your review. Supposedly PRs can't be merged until you approve.

And yes, we can take up the war on Informational EIPs later. I'm fine with them, but want to tighten up our standards.

@gcolvin As long as there is at least one editor approval, you can merge without your super-admin powers. 😃 For example, I can merge this right now despite there being a change request review. That being said, if you are uncomfortable merging while there is a red mark on the PR I can convert my review to a comment. I have a mild preference to leave it as a red mark just because I do think that this shouldn't live in this repository and I would like that to be documented as such.

@MicahZoltu Point taken. Merged.