How should we pick EIP numbers?

[SamWilsn]

In light of recent events, the discussion on how to assign numbers has come up again. This issue is solely for discussing assigning EIP numbers, and other topics will be deleted.

I'll try to summarize the proposals here, in preparation for the next EIPIP meeting. I'm going to give each proposal a short-name for easy reference.

Slug	Description
status-quo	No change; editors continue to assign EIP numbers arbitrarily, loosely based on the Pull Request number.
seq-bot	A bot assigns an EIP number N in the commit when merging a Pull Request, where N is exactly one more than the largest existing EIP number.
rand-bot	A bot assigns an EIP number N in the commit when merging a Pull Request, where N is equal to: R plus the lowest unassigned EIP number and R is a random number such that 0 <= R < 100; rerolling if N is an existing EIP.
seq-rand-bot	A bot assigns an EIP number N in the commit when merging a Pull Request, where N is equal to: the largest existing EIP number plus a random integer R, where 0 < R < 11.
deny-list	Create a known list of vanity numbers that are skipped, otherwise the same as status-quo.

[xinbenlv]

This is a competing proposal, if not, at least relevant to #5082

[Pandapip1]

Would like to add the following:

Slug	Description
eip-number-nft	An EIP Number NFT must be burned and linked to the Pull Request. 100 un-owned EIP numbers are assigned to each EIP editor at all times, and a transaction can be submitted that randomly burns one of those and gives a new number to the editor.
eip-number-nft-on-layer2	Identical to eip-number-nft, except on a Layer 2 network (since we don't need all of the security that Ethereum provides). The smart contract would support meta-transactions with OpenGSN, and the editors would be responsible for ensuring that the fees are always paid. A GitHub action could also be added that automatically assigns a random EIP number using its own pool of NFTs. Again, EIP authors get some freedom to pick their numbers.

EDIT: Prototype done (https://github.com/Pandapip1/EIPNumberNFT)

[abcoathup]

The perception is that "insiders" get treated differently rather than a consistent approach.
Random numbers would remove this perception around EIP numbers.

PR/4444 didn't have its number changed even though PR/4439, PR/4440, PR/4441, PR/4442, PR/4443, were all opened within a minute of each other, in possible attempt to farm a number.
#4444 (comment)

PR/4844 didn't have its number changed even though PR/4843 was missing for unknown reasons. (GitHub can remove spam issues/PRs)
#4844 (comment)

PR/4888 number was changed to a non-PR number for a manually created PR for a too early draft
#4888 (comment)

PR/5000 was requested to change its number for a bot created PR with spam issues prior and another editor merged the PR later without a number change
#5000 (comment)

PR/5222 number was changed to a non-PR number
#5222 (comment)

---

My vote is for rand-bot as it is less gameable and removes EIP editors from assigning numbers and any perception of fairness.

This doesn't preclude eip-number-nft on Layer 2 (not a sidechain) to offer low numbers to EIP authors if they prefer, with the potential to provide funding to make EIP editing sustainable.

rand-bot should start at a higher number, say 6000 to leave plenty of room for eip-number-nft

[xinbenlv]

@abcoathup while I 100% agree with your standpoint to make it less gamable and fairer, I don't think it would be trivial to maintain rand-bot to ensure such mechanism.

[SamWilsn]

I, unfortunately, have volunteered to write and maintain whatever bot we agree on.

[xinbenlv]

@SamWilsn of course, huge respect!
What I tried to say is that rand-bot is hard to maintain a fair randomness that's resistant to tempering.

[MicahZoltu]

@Pandapip1 Was there a reason you didn't include a trustless/permissionless NFT sale option? I don't see any reason why editors should have privileged access when we could build the system to be 100% autonomous/permissionless.

[MicahZoltu]

I'm generally against requiring all authors buy an NFT, so I think even if we did auction off old unused numbers we still would need a mechanism for number selection for people who didn't buy an NFT. For that problem, I like rand-bot. @SamWilsn Didn't you have two versions of the rand bot, one that guarantees larger numbers are newer and the other which guarantees that all numbers are eventually used (no holes)?

[Pandapip1]

@Pandapip1 Was there a reason you didn't include a trustless/permissionless NFT sale option? I don't see any reason why editors should have privileged access when we could build the system to be 100% autonomous/permissionless.

I thought that was implied. I'll make it explicit.

[tjayrush]

@SamWilsn of course, huge respect! What I tried to say is that rand-bot is hard to maintain a fair randomness that's resistant to tempering.

It doesn't have to be perfectly resistant to tampering. It has to be more resistant to tampering that the current system which is clearly not resistant to tampering.

[Pandapip1]

Edited the EIP Number NFT option to include a better option (IMO).

[SamWilsn]

@SamWilsn Didn't you have two versions of the rand bot, one that guarantees larger numbers are newer and the other which guarantees that all numbers are eventually used (no holes)?

Yep, I forgot to write it down. I've added seq-rand-bot to cover that case.

[Pandapip1]

we still would need a mechanism for number selection for people who didn't buy an NFT

The previous iteration did have a method to allow this, but I've had a better idea. Edited to include this better idea.

[TimDaub]

I'm against creating a ban list as it arguably won't work as number aestetic perception is subjective. E.g. the folks at Gnosis somehow got a palindrome 5005 while 5222 was argued away for being "too nice".

As design criteria, I'd aim for making the number assignment as little arbitrary (no human decides) and as little human controllable (no human can hack) as possible. If beautiful numbers arise from this process and we can all agree it was just luck, that's good.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[Pandapip1]

I think we've selected seq-rand-bot

[Pandapip1]

@SamWilsn just double checking this is the case?

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[Pandapip1]

This is in progress.

[github-actions]

There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback.