Topic: [ANN] [10X] 10X - an innovative gambling and trading game based on the Ethereum (Read 3073 times)

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.

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)

I am very excited to see 10X. I hope that the dream is beautiful. The profit of each coin after listing is 10X. I hope that everyone's investment can be maximized.

Here are some news.

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 before
2- 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 paper
3- 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.

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

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 ETH
Then 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.

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

There is a problem, after a long conversation with G_O in discord, and after thinking about eranl said, it seems that there is a technical problem to update the value of the token at the stock market.

I was supposing that the exchanges are reading the contract and scanning all the owners and how much they own. The ERC20 protocol being used to transfer, authorize, buy, sell.

But how the exchanges are interacting with the contract? and how they know the buy/sell orders from other exchanges? is there a protocol, an api that allows all the exchanges to share their buys?

I hope that you will change your mind with time. Thanks for taking the time to review my project.

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

>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 had no use 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

I understand your point of view, since it is something that haven't been tested I agree that one can doubt about the relationship between the contract issuing tokens and its value on the market, I think that [https://www.cryptotraders.eu/what-is-the-erc20-ethereum-token-standard/](https://www.cryptotraders.eu/what-is-the-erc20-ethereum-token-standard/) is a good reading.
The standard ERC20 gives the possibility to check all the balances of a token and from that calculate the value of this token. Since the contract can add more address and new balances, these will be scanned by all the exchanges we will deal with, and if something change it will be reflected in their walls, and change the global value of the coin.
If it was not working like this, different exchanges would have different prices.
Even if no one trade this coin, every time the contract will have any activity it will be reflected in the exchanges as soon as it changes the balances inside the contract.

>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 is corresponding mode is off. So the UI play and contribute buttons are actually calling different functions

I cannot split the contract in 2 addresses (did I understand your question well?). The balances of the token owners must be attached to the contract itself. I cannot move the money of the shareholders elsewhere or it would disappear from their wallet, and I cannot duplicate it because the token is attached to the contract address. I have thought about this solution at the very beginning of the development of this project, but had quickly to forget it for the reasons I mention before.  Also think about this, if another contract on a different address could interfere with the 10X contract, and the source code is public, what could stop anyone to steal all the balances?
In the case of talk about 2 different contracts on the same address, then it seems that you suppose that the UI will generate the transfer with the press of a button, but this is not possible. The player needs to log into his wallet, we cannot do it for him. So he needs to send money the same way he would participate the an ICO.

>For example you can add the option to bet on 10x tokens instead of ETH
>
I thought about it too in the course of the development. Receiving payment in a token value is a complex task to do both for the player and for the contract. Sending 10X would add confusion to an already complicated lottery system. Also the contract is not interested in getting 10X back, it wants Ethers. The decision was taken to keep the lottery as simple as possible (bet 1 get 10 if you win) and use the exchange for dealing with the token.

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 think that the exchange take all the balances of the contract and calculates the value of the coin relatively to how many coins are owned and at what price.
That's why a purchase on one exchange shows up in another exchange.

So I think (but I am not sure) that a purchase done by the contract should be visible in all the exchanges since it is an operation done using the ERC20 protocol and that the balances have changed.
In that case the contract is a mini exchange, selling 10X tokens at 0.1 ether per 10X...


>They buy the tokens at the lowest price that is asked on all the exchanges.
This is not wanted technically. Well it would ask me to use Oraclize to get the current price of the token which would be a mess and open the token to possible problems in case of Oraclize is not working for example. I want to avoid using it so that the token is 100% managed by the the Ethereum blockchain.

>Meanwhile the house makes profits by holding it's 10X tokens and slowly selling them off over a certain period.
I do not want the token to manipulate the price to this extend, I think that giving a little advantage the way it does now is enough to drive the price up and motivate the traders to play with it.
The trading part of the game is that every time a player lose and inject this money in the coin value, someone will take advantage of it (because the price goes up for example).
Smart traders will make gains, others will not. Who is going to get these 0.1 ether / 10X in his pocket is another part of the game.

well its not late yet just make sure to be precise with your answer and be honest about this project even you are a newbie but if you got something to
offer I think that's already a good basis to support you just keep updating the community maybe there's already some big investors which reading and
assessing this project, good luck to you dev.

Well yes, if the player where to buy these tokens from other people on exchanges at 0.1ETH a piece it all makes sense.

But if you just hand over these tokens through a contract (the additional 10,000,000) nobody could sell anything. There are just more tokens now and nobody has managed to sell his tokens.

In this fashion it would even make more sense if you put no number on what people bought the tokens at. They buy the tokens at the lowest price that is asked on all the exchanges. Once they bought up that they will proceed to buy at the next lowest price, ... Since people are greedy by nature they will keep undercutting each other anyway. So you will not have people who are selling it for 999ETH a piece. Becausse somebody would be happy selling it at 998ETH a piece, ... The lowest price that people are willing to sell it is at the price they bought . They people who bought will not get 10 tokens but they will get the tokens they could afford at such a price. It's an infinite pyramid scheme this way. Quite brilliant I would say. It would only fall apart if no more people where playing.

Meanwhile the house makes profits by holding it's 10X tokens and slowly selling them off over a certain period. (Not all at once since that would ruin the concept)

I am a newbie at bitcointalk, true. I am not into talking in forums, I like the shadows.
This forum is great, I regret to not have subscribed before.

I agree, but to be fair, a lot of of folks have been lurking here for a long time.

>Then please refrain from posting confusing stuff in your discord.
I apologize for that, I just keep people tuned about what is happening behind the scene, and I agree sometime it is confusing even for me.

> minted or not.
These tokens are not minted. 20,000,000 tokens are created at the contract creation and owned by the contract.
A maximum of 10,000,000 will be sold at the ICO. What is left stay in the contract and are used to be delivered when the player lose his bet.
Because we deliver 10 time the bet, the price of the token that the player actually paid is 0.1 ether / 10X tokens.

Nobody will pay 0.1 ether per 10X, but the player does, without having the choice, it is just a rule of the game. In another game he would have nothing.
Now his token can be sold in the exchange at the current price of the 10x. If he is not into trading, he will probably keep these tokens and do nothing with them.
But the number of token in circulation has not changed, some tokens have been purchased at xxxx% more than the current trading price, and there is a new token holder who own these tokens and has a good chance to be a pure newbie.

I don't know how this will show up in the exchange, but because tokens change hands at 0.1 ether, and no tokens were minted, it should show up as a buy at 0.1 ether in the buy wall.
I am really curious to see what will be the comments of the traders about that. When they will realize what is happening, it will be very interesting.

In my opinion this system should drive the price of the token up considerably.

If you see something wrong in the business model, I am interested to debate about it.

Then please refrain from posting confusing stuff in your discord. Either way there is one thing I do not understand in the entire concept. When people loose will they buy Tokens on the exchange at a price of 0.1ETH or will new tokens be minted at a price of 0.1ETH. If they are minted at such at that price there is no reason for people to buy it really. Since people will dump immediately for gainz. What point would holding do good? Not a lot of people would be holding since just having the tokens would not really do anything and more tokens will be created over time.

Now if people where to buy the tokens at the exchanges for 0.1ETH a piece...

And filling all the sell orders this would make more sense to me.

I apologize for my rash behavior but do try to post consistent news.

The rest of the project seems very solid to me, I just do not see how minting tokens at 0.1ETH a piece would drive up the price.

About the problem with the website, it is just something to do with our ISP. Do not rush too quick to conclusions.
Just be patient and the website will come back.