Contract variable changes prediction

Question

I believe this is a very simple question, but i couldn't find a direct answer in documentation or google. I'm new to solidity/ethereum and maybe i don't fully understand some core concepts yet.

So, let's use a simple code like this

contract StrangeToken {

  uint256 private repurchasePrice;   
  mapping(address => uint256) balances;

  function setPrice(uint256 price) {   
   repurchasePrice = price;   
  }  
}

Anyone can call setPrice() function to set a repurchasePrice variable. Let's assume that there are thousands of users and setPrice() is called every minute or even more often and the value is set to some random number.

The questions is: how difficult is it to predict and/or influence the value of repurchasePrice for the nearest future/coming blocks.

As far as i understand ethereum does not necessarily keep a sequence of calls so there is no practical possibility to time the call, so attacker has to be at least a miner, not a ordinary user. But the possibilities of miners in this area are not completely clear to me.

Thanks!

Answer 1

I'm not sure I understand your question completely but I think I get the gist of it.

With the publicly accessible function that lets anyone change the number, there is no obvious way to predict the next confirmed number because transaction order isn't established until a block is mined. The winner will always be the most recent mined transaction.

Everyone can see the candidates as pending transactions (with somewhat different views of ordering due to network latency).

I cooked up a slightly modified example that might help illustrate what's going on.

pragma solidity ^0.4.13;

contract NotSoSecret {

    bytes32 public secretHash;

    // put some money in with a hashed secret

    function deposit(bytes32 _secretHash) public payable returns(bool success) {
        secretHash = _secretHash;
        return true;
    }

    // if you know the magic word, you get the pot

    function claim(bytes32 password) public returns(bool success) {
        if(sha3(password) == secretHash) {
            msg.sender.transfer(this.balance);
            return true;
        }
        return false;

    }
}

This looks a like it should work, but it won't. deposit accepts funds and a hash. It looks like one needs to know the password to claim the booty.

In reality, what will happen is someone who knows the password will send a transaction to claim and that unconfirmed transaction will be broadcast to the network (miners and full nodes will hear about it).

That will encourage a race, because everyone will see the password. So, when an attacker uses that knowledge to make their own transaction (to claim the reward for themselves), they will have (roughly) 50/50 odds of success. Why stop at one try? The contract could be bombarded with claims once the secret is revealed.

Hope it helps.

Answer 2

The questions is: how difficult is it to predict and/or influence the value of repurchasePrice for the nearest future/coming blocks.

As per my understanding and the way I get your question, The prediction of the value of repurchasePrice has nothing to do with solidity or ethereum itself, but the benefits that a user gonna get setting the price there, means it has to be looked in an economical aspect rather than a technical aspect.

so attacker has to be at least a miner, not a ordinary user. But the possibilities of miners in this area are not completely clear to me.

In a miner perspective, the primary task is to find a valid hash depending on the difficulty of the mining time. If he tried to broadcast a block with invalid transactions (lets say to attack your contract) , when it get validated, since the transaction is invalid , the block he mined will be rejected.

So the way to attack your contract is to send a valid transaction but exploiting a loophole of your contract. So what you can do is to follow the best practices of developing secure contracts. You may refer links: the soldity docs and this post writing secure solidity.

The DOA attack is good example why you should write secure solidity codes without letting other exploit your contract for their benefit.