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 contractYou 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

Yes exactly I came to the exact same solution. I will open an account at one exchange partner (have many to choose from) and this account will be used to sell the ETH that are above the threshold value needed to run the game at current market price.For example I could keep 200 ether to insure that the bank cannot be insolvable and the game can run as designed with a maximum bet of 1 ETHThen all ETH above this number will be placed at buys at market price within this partner exchange.Traders will then wait that I dump these ETH and make gains.. I am a day trader, I will be in the line to collect these bonuses!

I could add a "bonus delivery warning" in a mailing list and on the website with a counter, so that people rush trading when this happen. It is even more fun that it was designed before!

What do you think? I think it will do the trick right?

I might need to consider changing the game into a x5 instead of 10x so more ETH will be collected more easily. X5 from 10 chance is still very high compared with the very popular local lottery here that are giving about the same but with a draw that can be 1-100.

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

Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

I have contacted 5 exchanges to ask them how do they process to calculate the price of a token, since they do not communicate through any transparent protocols with each other and basically are at war to get the most customers.None answered.

So it seems that the transactions between the contract and customers directly are not taken in account, which is weird, but that's my understanding. This asks me to change the description of the project and adjust some parameters.

I have made a tool to check the gameplay with different parameters: [http://10x.bz/n669.php] (http://10x.bz/n669.php)Based on the result of this simulation, the new business model would be like this:

The Lottery redistribute x5 (and not x10) for starting, and maybe distribute more if the reserves reaches the point where it is save to increase the distribution. Which is way safer, and needs a little bit of ETH to secure the bank.50% of the benefits would be reinvested into Advertising, 50% would be sold in an exchange (HITBTC is my favorite one) at market price (this can be adjusted if there is no need of this advertising budget).

Every dump will be advertised as a bonus event for the traders on the website with a countdown. I would use the exchange API to do the sale.

Any feedback? Check the simulator to see what parameters are best.

To resume, what would change is:1- redistribution to the winner = 5 times / was 10x before2- the winner receive tokens, he can resell them anytime but it does not show as a 0.1 ETH / token purchase (the exchanges are not able to do that). So I need to rewrite part of the description both in the website and the white paper3- the threshold to run the game will be extremely low which guarantee that ICO or not, the game will run.4- the benefits of the games are splitted into advertising and buying the token at market price.

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 list4. 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)

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 list4. 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)

Lot of interesting comments. - About the hash, you are right, but I don't see how to overcome this problem. The best solution would be to use a salt and something like blowfish, but it would cost too much gas to include this into the contract. Otherwise every solution I can think of, including your suggestions are not hacker proof since both the parameters and the return result are known and public. Also I do not want to have something too complicated to manage with the risk to forget the password and not being able to remember what was the last hash...This password system is good to discourage the guy who stole your computer, but if a pro hacker do it, there is nothing to do.I published the password contract separately at Github [here](https://github.com/TheWolf-Patarawan/PasswordClassSolidity)

- About the kill-switch I got the idea but I think that the isPaused function is doing this job (block the contract) and the destroyContract function is killing the contract too. So I think that there the functionalities are already here.

I will publish the tarpitting code, because I don't think anyone did it, I removed it from the 10X contract because it was taking too much gas and was not really useful.

Also if you are a programmer there an interesting idea, based on what I learned from the way the exchanges are working.The idea would be to modify the ERC20 standard to also store every transaction (buy/sell) in a public table with the source and dest address, and in return calculate the price of the token based on the values transmitted.That would greatly enhance the traceability of the transactions in the Ethereum world.