Add ERC: Future-block oracleless randomness

[angrymouse]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eip-review-bot]

File ERCS/erc-7977.md

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

[bomanaps]

Don't you think this could theoretically allow collisions under malicious input. We can tru using abi.encode(blockhash, requestId) or structured hashing (e.g., EIP-712 style), which is unambiguous.

[angrymouse]

By input, do you mean requestId?
I think the only risk would be if the requestId is the same across different requests - making it easier for validators to manipulate them all at once. But as for other factors, since blockhashes are not defined when you get requestId, there shouldn't be a problem with collisions.

[angrymouse]

CC @SamWilsn

[angrymouse]

I could not post this on ethereum magicians for some reason. Any thoughts why?

[github-actions]

The commit 9c5872e (as a parent of 86efa2f) contains errors.
Please inspect the Run Summary for details.

[angrymouse]

@SamWilsn

[SamWilsn]

Unfortunately this proposal does not seem like a good fit for the ERC process. EIPs/ERCs exist to promote interoperability between independent implementers. Generally we require that there be multiple implementations on both sides of the standard. For example, tokens are a good fit because on one half we have many wallets and on the other half we have many different tokens.

This proposal looks like it'll have a single implementation to generate randomness, which can be picked up as a library by contracts that want it. Instead of an ERC, this proposal should get API documentation and its own git repository.