Remove or make entropy message parameters optional?

[luca992]

env.block.random could probably be used for entropy instead of having the user specify it as of secret v1.9.0, what are your thoughts on making entropy optional or removing it entirely? @baedrik

I made a branch w/ it removed for example:
https://github.com/eqoty-labs/snip721-reference-impl/tree/remove-entropy

[baedrik]

Actually, I believe you want user-supplied entropy. Otherwise, someone would be able to determine the starting seed by pulling the block info for the block the contract was instantiated in. And then use the spicy printf storage issues to find the likely txs where someone does a create viewing key tx, and pulling that block info, they'd be able to figure out the viewing key created. Having the user-supplied entropy creates unknowns that can't be determined from chain/node analysis

[luca992]

hmm when is the supplied random actually useful then haha?

[baedrik]

It's still useful for randomizing events that "end", so that knowledge of the outcome doesn't have a persisting effect. So gambling outcomes, random minting, etc...

[baedrik]

Actually I heard that the block only provides the entropy and that every contract call will get a diff random, so you should be able to use it.

[luca992]

Actually I heard that the block only provides the entropy and that every contract call will get a diff random, so you should be able to use it.

Sweet, for sure? That would make wayy more sense... Because I was thinking it would be exploited really easily to do something like:

Assume you wanted to make theoretical contract whose goal would be to only flip a "coin" saved in another coin flipping contract to heads everytime. I was thinking you could just duplicate the contract except after calling flip if it returns heads it would send a message to the original contract to also flip the coin, which would have the same block info I was thinking?

[baedrik]

Personally I would probably still test it out, since I don't know how it was implemented--only heard the intent. Like write a contract that has an execute that outputs the random in a log, and have a test that would log the random one contract sees, and then does a callback to another instance which outputs the random it sees.

It would probably also be good to have a query that just outputs the random. And then see what random the query returns vs what random an execute in the same block gets. Since queries are not broadcast to the entire network, that would mean that a query isn't going to force a change in the next random retrieved (otherwise it would break consensus when one node processes an execute that uses random after a query that retrieved the random vs a node that did not receive the query first). So while getting different randoms for subsequent executes in the block will prevent the issue you describe, if a query can still leak what random an execute by another contract got, there will still be times you want to avoid using it and use entropy provided by the user