The Meebits Exploit and a work around

Security
1

I'm new to ethereum development and NFTs. I've read https://www.paradigm.xyz/2021/10/a-guide-to-designing-effective-nft-launches/ and the more about the meebits exploit.

Two of the requirements for the NFT contract I'm trying to write is it must be a non-exploitable random, and it should only require one transaction to purchase an NFT. Using VRF is not desirable because of the client thinks it is too costly.

I've been racking my brain to figure out if this is possible, and have come up with a solution that I'm sure has a weakness that I don't know about so I wanted to pitch it here and get the advice of people who have a lot more experience.

When you mint you essentially mint a mystery box and create a "random" number like meebits that is stored:

uint index = uint(keccak256(abi.encodePacked(nonce, msg.sender, block.difficulty, block.timestamp))) % totalSize;

Then, you open the last mystery box that was minted, by rolling another random index like above and combining it with the random number rolled by the that mystery boxes transaction to come up with a new final NFT index.

Now a NFT resolves over two transactions so it can't be exploited like meebits.

Is this possible or am I wasting my time?

1 Like
2

splitting the generation of a predictable "random" number into two predictable "random" numbers doesn't make it secure. VRF is preferred because it generates randomness off-chain. It's impossible to have true randomness on the EVM without and outside source.

Your one transaction requirement might not be possible. The next best solution is to provide randomness yourself and use a commit-reveal scheme, which requires two transactions from you and one from the user (this can be optimized by making multiple commits in the same transaction)