Delete EIP-5000

[MicahZoltu]

This appears to be authored by someone actively attacking the EIP numbering system. Not only did they appear to number snipe, but they blatantly ignored editor number assignment and picked the number they wanted anyway. It was merged, but I suspect the editor who approved it just missed the assignment comment because it was marked by GitHub as "resolved".

Timeline:

• At around 18 minutes after the hour, a spammer created issue https://t.co/IRMCnNRMaV😂https://github.com/0xProject/0x-launch-kit/blob/master/launch-kit-banner.png #4998. This has since been deleted as spam.
• At around 19 minutes after the hour, a spammer created issue . #4999. This has since been deleted as spam.
• At around 19 minutes after the hour, @hrkrshnn created PR MULDIV instruction #5000.
• An hour and 7 minutes later Sam reviewed it and assigned number 4998 with a comment indicating why 5000 wasn't assigned.
• ~18 days later (with no updates from the author) lightclient reviewed it
• ~Over two months later (still no updates from the author) lightclient reviewed it again
• About an hour after that the author made the first change to the PR, in which they ignored Sam's assigned number and took 5000 anyway.
• Review proceeded from there as normal and it was eventually merged.

---

We have a serious spam problem on this repository and it is a huge editor time sink. At best, the author of this PR wasn't the spammer but they were running a number squatting bot and they blatantly ignored editor number assignment. At worst they are also the spammer and part of a serious problem.

I propose we delete this EIP and potentially ban the author from the repository for this behavior. The blatant disregard for an editor's number assignment without discussion combined with the blatant number sniping makes me classify this as an active attack.

---

Also, since an editor is a co-author on this EIP I think this case should be taken far more seriously than normal. Editors should be held to a far higher standard than regular drive-by authors and while I am not suggesting @axic played an active role in this attack (they may not have known about it), I think that a strong show of intolerance against malicious behavior here is necessary due to this association as we cannot be seen to be giving preferential treatment to editors.

[eth-bot]

A critical and unhandled exception has occurred:
Message: not found
Data: (there is no data for this error)(cc @alita-moore, @mryalamanchi)

[MicahZoltu]

cc @axic @gcolvin @SamWilsn @lightclient @Pandapip1

[MicahZoltu]

Also cc authors @hrkrshnn @axic @chfast

[MicahZoltu]

Note: If this PR is approved someone can create a new EIP with the same content, but a new editor assigned number. The purpose of deleting this rather than just changing the number is to show extreme intolerance for this type of behavior by making the authors go through the whole process again and making it very clear that this behavior is entirely unacceptable.

[SamWilsn]

I'd rather just rename the file and renumber the EIP. Seems a tad melodramatic to delete the EIP 🤷

Effectively it'll be the same thing.

[MicahZoltu]

If there is no punishment at all to the author here, it incentivizes people to try to game the system because there is no risk to trying. By making them suffer in some way (in this case, having to submit a new EIP), it introduces at least a little risk to those who game the system.

I think it is important that we make it abundantly clear that this behavior is unacceptable and there is a real cost to the author rather than us just fixing their attack for them. I feel particularly strongly about causing pain/suffering on the author because an editor is a co-author and because they deliberately ignored the editor assigned number (I find it very hard to believe this was an accident), so I think we need to set a very strong and firm example.

[Pandapip1]

Anyways:

• +0 to remove the file. I agree that at most it will be an inconvenience.
• -1 to banning the PR author. I would be afraid that it would be interpreted as admin abuse if there wasn't a rule that covered situations in which such an action could be taken in EIP-1.

[SamWilsn]

I've opened a PR to renumber: #5270

[MicahZoltu]

Minor update on this situation: After speaking with some of the people involved in other public channels (Discord), I have learned that the authors petitioned lightclient privately to use 5000 and lightclient agreed and a separate private discussion with Sam resulted in Sam disagreeing with the use of 5000 but acknowledging that lightclient has the power to choose a number despite his dissent.

I find this situation to be even worse than the original, because it indicates that EIP editors are actively participating in backroom deals and giving preferential treatment to people who have the right connections.

If I was dictator of the EIP process, I would likely fire or otherwise severely punish Alex, and Lightclient for collusion and preferential treatment. I feel like all parties involved SHOULD know that this sort of thing undermines our credible neutrality, even if it seems like a fairly minor issue, and it has been made incredibly clear in the past that the EIP system MUST remain credibly neutral for it to continue to be seen as a legitimate part of the Ethereum governance process. Sam does appear to have acknowledged this, but I do think he should have brought the issue into public discourse rather than allowing it to occur behind closed doors.

Unfortunately, I am not a dictator and since it seems that the majority of the active editors are in on the collusion the best I can do is appeal to the editors to do the right thing after the fact and correct the issue with extreme prejudice and in a way that makes it incredibly clear that lessons have been learned and this sort of favoritism will not happen again.

[leonardoalt]

1. If I was dictator of the EIP process, I would likely fire or otherwise severely punish

2. Unfortunately, I am not a dictator

3. I have never before considered a coup to take over the EIP editing process, but stopping favoritism/favor trading/backroom deals is apparently the thing that may turn me into an illegitimate dictator.

What?!

I am not involved in this EIP, but I find the statements above extremely worrying.
How come no one finds it unacceptable that an editor wishes they were a "dictator of the EIP process" and publicly state that they want to throw a coup?! So much for neutrality.

[MicahZoltu]

My comments weren't meant to suggest that I want to be a dictator, nor that I have any plans on engaging in a coup of any kind. I merely wanted to make it clear what my position was by imagining a world where I had full decision making power to help illustrate how severe I think this situation is.

[gcolvin]

1. If I was dictator...
   What?!

I am not involved in this EIP, but I find the statements above extremely worrying. How come no one finds it unacceptable that an editor wishes they were a "dictator of the EIP process" and publicly state that they want to throw a coup?! So much for neutrality.

I'm accustomed to this sort of hyperbole from @MicahZoltu ;)

And I understand why he's upset.

In the old days, people usually started out by opening an issue, which then became the EIP number. Otherwise, the first PR became the EIP number. They come from the same series. The editor making the assignment was pro forma. So this sort of unpleasantness pretty much couldn't happen.

The only gaming that happened was people repeatedly opening issues to hit a magic number. As I recall it, a very stern public scolding or two from @Arachnid put an end to that. We're enough of a community for social pressure to work. I'll take this as a very stern scolding from @MicahZoltu and leave it at that.

PS. There remains a fair way to game the system -- follow the PRs and issues until a number you like is next. You might even read them and contribute to the work.

[Pandapip1]

PS. There remains a fair way to game the system -- follow the PRs and issues until a number you like is next. You might even read them and contribute to the work.

I will say that it is definitely more than a little suspicious that two spam issues and the EIP-5000 PR were opened within two minutes.

[lightclient]

I admit that not having this discussion amongst editors in a public channel was a mistake, and going forward I will not make a similar one. The choice was not made in malice, but rather a genuine oversight as I felt the issue insignificant.

--

As to why I considered the issue insignificant and believed I had the agency to merge #5000, I have in the past been in favor of letting authors who I believe legitimately got an interesting number retain the number, especially if it is a project that will actually make use of it. Maybe you disagree with that policy, but it is how I have previously approached numbering issues and I didn't feel my actions deviated from that.

There is no official policy on issuing numbers. Irrespective of the authors, I felt that this is an EIP that merits an interesting number as it has a high likelihood of becoming part of the public discourse (ACD, FEM, etc) and a reasonable chance of being included into the protocol. I don't have an official policy on what EIPs I consider meriting interesting numbers, but see above link for how I have approached this in the past.

I overlooked the preceding spam, because it is impossible to know with certainty who was the culprit. They created a bot to snipe the number so I don't know why they would also need to spam. Had this been an EIP from an unknown author, I would've reacted more harshly to the spam. However, the authors of the EIP have show historically that they are honest and legitimate contributors to EIPs. I don't consider this favoritism. I think it's okay to give regular contributors the benefit of the doubt.

This [EIP-5000] appears to be authored by someone actively attacking the EIP numbering system.

The authors of the EIP are clearly not attacking the EIP number system and this hyperbolic statement is unnecessary. In general, I think the tone of this PR is unwarranted.

--

I propose we close this and #5270 and move on. I don't think any action here will discourage future authors from trying to get an interesting number. The only outcome of these actions is "pain/suffering", which IMO is not an acceptable approach for a technical repository.

If we want to change how we currently approach numbering, we should discuss on EIPIP.

[MicahZoltu]

It sounds like we agree on the series of events, but disagree on whether they are problematic or not. In my eyes, the problem here has very little to do with the actual sniping (though that is a problem that I think should be addressed as well), and far more to do with the process around how things were handled. In particular, the following is the public record:

1. The submitting author is an EIP editor, and I believe they should be held to a higher standard of neutrality than everyone else.
2. Sam assigned a different number and this wasn't respected/applied/responded to by the authors at all.
3. Sam's public dissent was overruled by lightclient without any public comment.
4. The timing of everything involved is conspicuous, as the EIP sat idle for 2 months, and then the authors set the number to 5000 and it was merged by lightclient 30 minutes later, with no time for anyone else to engage in the discussion over whether this is acceptable behavior or not.
5. Lightclient played favorites with the authors of this issue, which I strongly believe editors should not be doing.

Regardless of what is true or not (something we cannot know other than through trust relationships), to an outside observer I think the most compelling narrative goes something like this:

1. An editor who knows how number assignment works setup a bot to snipe arguably one of the best EIP numbers to come around in a while.
2. The editor intentionally left the EIP number field blank, so it would appear less like number sniping since the official rules are "editors assign a number".
3. An editor very quickly assigned a number that wasn't the one the authors hoped for.
4. The authors ignored the number assignment for 2+ months while they worked behind closed doors to get the number they wanted.
5. The authors eventually convinced another editor through in-person connections, closed door meetings, and unknown private agreements to override the original number assignment.
6. The authors and the merging editor colluded to change the number and merge the issue in quick succession to limit the chances that any other editor would object in time.
7. The authors and editors involved chose not to discuss any of this publicly, because they knew that other editors would vocally and strongly object (e.g., Micah).
8. The authors/merging editor assumed that if they managed to get the PR merged, the desired number selection would not be overruled, even if there was disagreement afterwards from other editors.

Again, the above may be fiction, but it is the most compelling story based on the publicly visible evidence.

---

It sounds like you (@lightclient) disagree that there is any problem with the above narrative (except perhaps with some of it maybe not being true), which I think is the source of our disagreement. The above behavior is exactly how governance capture works. People with friends on the inside are in a privileged position to game the system and trade favors or leverage connections in order to get things they want that aren't available to the general public, or to get special treatment that differs from the treatment the general public gets. You have acknowledged that special treatment was given because you think these particular authors are good people and they are more deserving of the benefits of a cool number than the general public is, so you gave them special treatment.

I think it is very important that the Ethereum governance process remains credibly neutral, and EIPs are a core part of that governance process. I think the above narrative (whether true or not) paints a picture of a very non-neutral system of governance and your admitted preferential treatment to certain parties further erodes the credible neutrality of the EIP process. In order to regain our credible neutrality, I think we need to show a willingness to fix this non-neutral-appearing decision so it is clear to third party observers that the EIP process is not an "old boys club" where friends of editors get treated differently than everyone else.

[lightclient]

The EIP process is distinctly different than the Ethereum governance process and, as I've stated in the past, I am okay being a bit more relaxed in the EIP process, because it does not affect the Ethereum protocol. Regardless, I don't believe the Ethereum governance nor the EIP process are currently at risk of capture. Creating drama around an inconsequential event such as the number of an EIP does more harm than it prevents.

The authors followed the correct procedure for creating an EIP and were able to obtain an interesting number. There is no reason to penalize them by renumbering their EIP. Anyone is able to get an interesting number (it even happens inadvertently, e.g. #5222) if they follow the correct procedure (as Greg said).

[tjayrush]

The above behavior is exactly how governance capture works.

As is almost always the case, I agree wholeheartedly with @MicahZoltu. This issue should be on the agenda of the next Core Devs meeting and, if the events described are true, @lightclient should be sanctioned.

I think it's that important because it shows that the process can be gamed, and if it's gamed once, it can be gamed again.

Of course, in this case, it was gamed for an issue that might be labeled as minor, but I think it's important.

The EIP should be renumbered. The number 5,000 should be "retired" and become a "sentinal" or "memorial" for the community to remember the time when someone tried to game the system.

[timbeiko]

As is almost always the case, I agree wholeheartedly with @MicahZoltu. This issue should be on the agenda of the next Core Devs meeting

FWIW, I think this is much more appropriate for https://github.com/ethereum-cat-herders/EIPIP

if the events described are true, @lightclient should be sanctioned.

What does this even mean? It's worth reemphasising that EIP editors have huge opportunity costs and mostly do this work with a desire to help Ethereum. Of course, mistakes happen, people are human, etc. but I think it's a fair assumption that everyone is working in good faith and the idea of "sanctioning" editors does not sit well with me.

[Pandapip1]

I disagree that this was as serious as an attempt at governance capture. Agreeing to a petition is not the same as a preferential treatment! Also, I feel that this needs to be re-iterated: this controversy is about an EIP number.

• If EIP numbers are really such a big deal, we shouldn't implement One-time NFT Sale of unused EIP numbers. #5082. If anything, petitioning to get an EIP number equal to the PR number would be somewhat fairer than buying it.
• If it was me that was directly contacted, I would have considered it. @lightclient made a decision that he believed was, and that is, completely insignificant.
• If the PR in question was, for example, a proposal to add one or more EIP editors, I wouldn't have even considered posting a comment on it until I had consulted with at least two other editors. I imagine that the same is true of @lightclient.
• EIP editors are free to assign any EIP number. If @lightclient thought it was rational to give them EIP-5000, then @lightclient didn't do anything wrong.

I don't care if the EIP is deleted or renumbered (although I agree one of those things should happen). But this isn't @lightclient's fault.

(I am also confused why they would go to the trouble of convincing @lightclient when @axic, who is both an editor and an author, could easily have done the same without much fuss... I'm not sure there's an EIP that I'm an author of where I haven't self-assigned a number)

[SamWilsn]

@gcolvin

I think you mean axic?

[Pandapip1]

Yes, sorry. Edited.

[MicahZoltu]

(I am also confused why they would go to the trouble of convincing @lightclient when @axic, who is both an editor and an author, could easily have done the same without much fuss... I'm not sure there's an EIP that I'm an author of where I haven't self-assigned a number)

Editors should not be reviewing their own EIPs. This is why the bot won't merge (I think we implemented this) if an editor is an author and approves, they need a second editor to approve. While Alex could have set the number when they created the PR (many authors do this), the editor that reviewed it can choose to re-assign (as Sam did).

[Pandapip1]

Editors should not be reviewing their own EIPs. This is why the bot won't merge (I think we implemented this) if an editor is an author and approves, they need a second editor to approve. While Alex could have set the number when they created the PR (many authors do this), the editor that reviewed it can choose to re-assign (as Sam did).

..and then technically authors can choose which number to choose.

[MicahZoltu]

..and then technically authors can choose which number to choose.

I don't understand what you mean here.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[MicahZoltu]

The bot is being pretty annoying about this, perhaps we should close this one and leave the renumbering open.

[Pandapip1]

The bot is being pretty annoying about this

That was the intent. I'm happy to see the prodding successfully keeps issues active!

[lightclient]

This issue is no longer being actively debated and should be closed.

[MicahZoltu]

Do you mean this issue specifically (deleting) or do you mean the broader issue of whether EIP-5000 should continue to exist as EIP-5000?

[lightclient]

I am referring to both.

[xinbenlv]

@MicahZoltu did you intend to withdraw this PR?

[MicahZoltu]

@MicahZoltu did you intend to withdraw this PR?

This is still my preferred solution, but I would support a compromised of the renumbering option (I forget what PR # it is).

This issue is no longer being actively debated and should be closed.

The conversation is at a standstill, but there is not consensus. I don't think we should give preference to the first mover here, especially given that a big part of the debate is around whether process was appropriately followed with the original action of overriding the public editor assigned number without any public discussion.

[lightclient]

especially given that a big part of the debate is around whether process was appropriately followed

What rule was broken in EIP-1?

[MicahZoltu]

On the surface: the rule of editor assigns a number. In this case Sam assigned a number and it was not used.

Of course, under the covers things are much more complicated than that since you engaged with the authors in private and gave them the green light without any public discourse or engagement with the broader EIP editor community, which as we have discussed is a big component in the actual debate (is it acceptable for editors to override other editors without broader editorial discussion). Had you engaged the rest of the EIP editors I would have opposed giving them 5000 for the same reason Sam originally opposed it, and in fact the only reason I didn't comment on the PR prior to your approval was because Sam beat me to it and I felt it was unnecessary to add a comment to "plus one" Sam's renumbering since I didn't think another editor would overrule it. FWIW, I did thumbs up his comment it appears, though I can't be certain if that was before or after the PR was merged and I don't think there is timestamped history for reactions.

The unwritten rule that was broken was the no-number-sniping which has been discussed off and on over the years in various locations, and especially number sniping that is accompanied by issue/PR spam (as this one was).

[xinbenlv]

An hour and 7 minutes later Sam reviewed it and assigned number 4998 with a comment indicating why 5000 wasn't assigned.

It seems to me an assignment already happened as 4998 prior to @lightclient's assignment as 5000 if @MicahZoltu 's documentation is right.

In this case, when first editor already assigned 4998 first, second editor to come in and assign a different number 5000, should the process consider first editor assignment legit or the second editor assignment legit? There seemed no indication of particular rule in EIP-1, but I am assuming there is an "implied rule" EIP's couldnt change its number after assignment unilaterlly by a single editor. (please distinguish from @MicahZoltu 's "The unwritten rule that was broken was the no-number-sniping' here"）

Which rule does it break in EIP-1?

If this "implied rule" is considered a rule, this rule is broken

If this "implied rule" is not considered a rule, then it's legit Sam first aasign 4998, lightclient later assign 5000 also legit, then Mical (being an active editor back then) later assigns back to 4998 is also legit.

Which way is it? Regardless, I think Editor shall be able to agree upon rules to do things in consensus, but "do things in consensus" is also not explicit documented thing in EIP-1 yet, so, maybe we shall just allow each editor to act in their own prefefence disregarding others concern? 😂🤣

[Pandapip1]

I personally interpreted the rules to mean that editors can assign a number and that authors are free to pick from among the numbers chosen.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[MicahZoltu]

Still needs a decision.

[SamWilsn]

#5270 has one more approval. I'll put that one back on EIPIP for the next meeting.

[github-actions]

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[MicahZoltu]

Sounds like #5270 is gaining traction, so I'm OK with closing this one and focusing efforts on that instead.