I had some thoughts about your password-protected functions.
The idea of securing your critical functions with additional password is very good, but the way you implemented it is not secure due to the publicity of all transaction input data:

- Once you call storePassword function to initialize your password, the data in this call is visible to anyone who runs full node.
- The data is also visible when looking at the contract transaction history (it needs to be disassembled but it is quite easy for hackers)
- Each time you call a function that is protected with password you also expose it in the transaction data and again it is visible

So i thought about how to have password protected functions in a secure way and here is what i came out with:
1. You need to set a password and calculate its hash offline. Then hard-code the hash value into the contract (or create a function to initialize the password hash)
2. Whenever you call a function that is password protected, you need to set a new password hash (since the function call data is visible to anyone). Therefore, you need to hold an offline list of passwords and their matching hashes and each password protected function needs to accept the next password hash parameter and replaces the current hash with the new one

* you may create a list of hashes and initialize the contract with the whole list. So you will not need to change the hash in each call, but just lookup the hash of the current password in the list and then remove it so it cannot be reused


Now there are some risks you need to consider:
1. Each password must be very different than the others to prevent guessing relying on previous passwords.
2. To prevent hash cracking you should also use a Salt value for the hashing - a long random string that you concatenate with the password before hashing. The Salt can be a single value stored in the contract (it will be visible but it anyway has its added value to prevent cracking the hashes with existing rainbow tables)
3. Since you need to have many passwords and make them complex and different from each other you will probably need to write them down somewhere, so there is also a risk you will lose access to the passwords and the risk of someone getting access to this list
4. There is also a race condition risk - when you submit a transaction to your contract with a password, before the transaction is confirmed in a block, the attacker (who has your private key, as this is the reason the password exists in the first place) can make a competing transaction with higher gas price, making it in higher priority for the miners. This way, the attacker use your hash to access the password protected function and if the function also replaces the hash the attacker can set the next password and now he is in control of the passwords and not you (this is why initializing the contract with a list of hashes is more secure)

And one idea i have regarding the case where your private key is stolen but you still have access to it as well:
- Create a kill-switch function with hard-coded password hash (that matches to a dedicated kill-switch password you have offline)
- This function will turn on a global boolean flag that indicates to all other functions that the contract is disabled forever (there is no function to set it back to false)
- Once you know your private was stolen call this function and the attacker cannot abuse his access to the contract (the race-condition attack is not a risk in this case as the attacker cannot use the password of the kill-switch function for any other functions and the kill-switch function will be called anyway)

Yes I guess this should work, just make sure your new strategy is well published so the ICO will be successful
good luck

One last thing I can suggest you is to promise to buy back tokens from users from time to time (according to your profits)
This does not require you to change the contract and it can definitely influence the token value. Maybe you need to mint less tokens in the first place and once the game tokens supply is over you buy more tokens from users from exchanges and move it to the contract
You will be the main first buyer that pushes the price up and when users will see it really happens they will gain more trust and start bidding for the tokens in the exchanges

Eran

I meant two different payable functions not two different contracts. I am not sure it is possible since I am quite new to Solidity, but i do see that your code already have two different payable functions in addition to the fallback one (the addEth() and makeTokens()) so it seems to me like it is possible

As for the tokens, I will not participate in the ICO as I am still not convinced the tokens will gain too much value over time but I am curious to see what will happen. I still think that it would be much better model if the tokens were useful or at least required in order to play, but I see how it makes the contract much more complicated due to the need to deal with both ETH and tokens transactions in the same contract

Thanks for your answers
Regarding the 10x tokens I am doubt about its exchange value will be influenced by the game rate of 0.1 ETH per 1 10x - you need buyers to be willing to pay for these tokens but one of the disadvantages of your design is that the 10x token has no value or use case in the game itself. I really think that you need to add some option to use 10x tokens in the game itself to get some benefits. For example you can add the option to bet on 10x tokens instead of ETH (in the rate of the exchanges) or maybe offer users the option to double their win by paying some 10x tokens in addition to the bet

Regarding the mode switching and preventing the users from doing mistakes, even when using the game UI, there is still a probability of race condition. I think a more appropriate solution will be to separate the payable functions - one for each mode - and refuse the payment when the function is called when its corresponding mode is off. So the UI play and contribute buttons are actually calling different functions

I have few questions regarding the 10X game and contract:

1. You are saying that when a player looses and gets 10x tokens at 0.1 ETH rate, it is like an exchange order for buying 10x in 0.1 ETH price.
But this is not true, the contract is paying the tokens from the contract token supply and it has nothing to do with external exchange trading. I don't see how this affect trading prices (and really cannot see how your claim that if i place a sell order for 0.1ETH price in the exchange, when i lose the game i might buy my own sell order)

2. There is the case of the game mode is on and then the ETH supply is running out so the mode is switched back to ICO. When this happens players that are currently active may send bets without knowing that they are not betting but actually contributing more funds to the contract.  How do you prevent this from happening ?

3. Same question as 2 but the other way around - when ICO mode is switched to game mode, there might be contributors that still send ethers to the ICO but instead they will play the game without knowing - again how do you prevent this from happening ?

Hi,
I have reviewed your contract and it seems fine except for one potential issue - the function addEth() is not onlyOwner - is this done intentionally ?