3

I developed a smart contract that you:

1) Send 1 ether to an address, the contract saves your address

2) After 5 people have sent one ether, the contract chooses one address at random and sends the 5 ethers to that address

I read here: What is the order and concurrency behavior of multiple calls to a contract in a single transaction?

that the miner decides the order of the transactions.

If more than 5 transactions are sent to the contract within the same block, can the miner game the system to enter his own transaction and execute the smart contract on the order he decides to win every time?

The winning address is chosen using 

        random = uint(block.blockhash(block.number-1))%5 + 1;

I know a miner gets 5 ethers per each mined block + fees, so that's why I limited the inputs to 5 ethers total. The random function isn't that random, but the low payout (I thought) should make miners not care about gaming it. Here's the code of the function:

function () payable {
    require(msg.value == 1 ether);

    my_length +=1;

    gamblers[my_length] = msg.sender;

    if (my_length == 5) {
        // pick a random number between 1 and 5
        random = uint(block.blockhash(block.number-1))%5 + 1;
        gamblers[random].transfer(5 ether);
        my_length = 0;
    }

Thanks

Anto
  • 311
  • 1
  • 3
  • 9

2 Answers2

2

Yes they can

Are timestamps (now, block.timestamp) reliable?

This depends on what you mean by “reliable”. In general, they are supplied by miners and are therefore vulnerable.

(...)

Never use now or block.hash as a source of randomness, unless you know what you are doing!

doc

There is more reliable way to obtain randomness with an Oracle. But instead of trusting miners you'll have to trust the Oracle and the data-source ( like random.org ). here for more technical way to achieve this.

Community
  • 1
0xCrema.eth
  • 1,182
  • 1
  • 12
  • 21
1

Technically, some players might be able to game this system, in addition to miners. Since you're using the previous block hash, a miner can simply wait to include a transaction to your lottery until the previous block has a favorable hash. Users can also attempt to get their transaction in the next block if the new chain head contains a favorable timestamp.

If both classes of user are trying to game the system, the miner can win by including their transaction in the block first.

Note that this would probably require a bit of custom infrastructure on their side, and probably isn't terribly likely... but the players being able to game the system is a more pressing concern.

DeviateFish
  • 1,128
  • 5
  • 11