152

There are a few trade-offs and key points to keep in mind in this area. Any decision that a user makes which affects the outcome gives that user an unfair advantage. Examples include: Using a blockhash, timestamp, or other miner-defined value. Keep in mind that the miner has a choice of whether to publish a block or not, so they could conceivably have one ...


27

Note that with linagee's suggestion, you're not just trusting random.org, you're also trusting Oraclize. Oraclize publish a TLS notary proof to show that the data they're giving you really came from random.org, but that's not enough for this case: We need to know that this was the only data they got from random.org. Otherwise they could keep trying and ...


13

You could use https://api.random.org/json-rpc/1/ which gives you a random source of data through JSON and Oraclize which allows you to make use of the feed inside an Ethereum contract and optionally have it strongly authenticated as having come from random.org. (Along with existing methods of using the hash of the block, timestamp, and such.) You would be "...


7

Since different contracts are securing different amounts of value, at the opposite end of the spectrum to RANDAO is the simple BLOCKHASH. If BLOCKHASH may suit your purpose, it's highly recommended to review the question (below is only a snippet): When can BLOCKHASH be safely used for a random number? When would it be unsafe? As a general rule, ...


7

Yes, by using the properties of hash functions. step1 with 2 transactions: A and B each submit a hash of (their bet + a random number) step2 with 2 transactions: A and B disclose their bet and random number as part of the 2nd transaction of step2: the contract pays the winner. Instead of writing the whole thing, here are a few ideas: function hashing(bool ...


6

The contract provide deterministic outputs there is no rand function in the smart contract. you could try to write your own rand function using for example the block time stamp as a base. However, for the vdice.io, I've looked(just a glance) into the code i've found they use an oracle(external source) to get a random value: bytes32 myid = oraclize_query("...


5

The short answer is you can't. RANDAO works, but it's slow, and if your game is popular, there will be a strong incentive for people to game applying the last number. I suggest using an oracle to provide randomness. (as mentioned in Tjaden Hess' Notes and Alternatives 2c.) The two major benefits are you can strongly assert that your number is independent of ...


5

Why not just use the official lottery figures from the television? For instance, the German Lotto Zahlen. Then you build in a voting mechanism where the players can vote on the winning numbers after the lottery numbers have been drawn and published on television. To incentivize also losers to vote, you could offer players to reimburse say 5% of their stake ...


5

It seems to me the various suggestions presented here all have in common a model in which a smart contract is acting as the server in what is essentially a regular ol' single-server/multi-client architecture, and much of the concern is that a miner will game the system - which is sorta the problem that has always existed when there is a single trusted server....


5

There are a few gambling Ethereum dapps under development, though not many are production-ready. I'm not aware of an existing comprehensive list like you describe (though this site has a good list of dapps in general, some of which are gambling games), but here are the ones I'm aware of: Pokereum - Poker (crowdfunding soon, mostly in private repo) Powerball ...


4

To do it in practice, use a Chainlink VRF. Conceptually, use this answer. To make the random number, we need a few variables: keyhash: The public key hash of the oracle(s). This is to make SURE they are making a random number based on the seed we give it). We are going to use the ropsten Chainlink VRF oracle. userProvidedSeed : A seed of our choice, this is ...


4

There are currently 2: etheroll.com (live) random number is generated entirely on blockchain etherdice.io (shutdown until further notice) random number uses 3rd parties You can view the full list of available smart-contracts here: http://dapps.ethercasts.com/


3

The reason that this system is secure is that the two players must submit the hash of their random seeds before any betting takes place. This is called non-malleable commitment, and it ensures that the players cannot change their seeds after they see all of the bets. The inclusion of the blockhash, number, and timestamp is to ensure that even if the two ...


3

I've been pondering a similar question. As I see it, the first transaction would instantiate the game, and transactions coming afterwards would advance the game state one step per transaction. Each step would need to be verified (one new block would need to be mined) between each round. Example: contract Game { mapping (address => uint) playerSteps; ...


3

Yes, there's nothing stopping you from having multiple turns, with each new transaction on a block being a new turn. You do have to be mindful that all data from previous turns will be public, so make sure you're not leaking information that other players shouldn't see.


3

There is no true randomness in contracts. In this case, the contract is requesting that Oraclize fetch a random number from random.org. You are trusting both that random.org is honest, and that Oraclize doesn't call random.org several times looking for numbers that benefit it.


2

I don't know the best secure method, but please see bellow a list of Vulnerable implementations (so finally do not use): PRNGs using block variables as a source of entropy PRNGs based on a blockhash of some past block PRNGs based on a blockhash of a past block combined with a seed deemed private PRNGs prone to front-running You may take a look on ...


2

I have an idea that builds on Tjaden's protocol that I outline here: Is this approach to an ethereum lottery sound and/or novel? It solves the problem of having to put up a large security deposit in lotteries. Would appreciate some feedback.


2

Lets think that you are using a block hash to decide a lottery winner and miner A participates to that lottery and buys one ticket. Then he mines many valid blocks and throws them away, if they are not suited to his ticket. In practice, every valid block that a miner throws away costs him 5 ethers. If your lottery's odds are so, that miner A has to eg ...


2

Securely generating a random number is difficult because of the deterministic nature of the EVM. There are many approaches. Which one works best depends on your security requirements and context. Here are a few: Previous block hash If your random number is not security critical, you can simply use the previous block hash. E.g. a random number from 0 to 99: ...


2

I've published eth-random, which is a simplified guide about how we implemented RNG on CryptoKitties. There are some caveats about it, but to this point I haven't seen a single founded hack attempt on it. Update 1: For a practical example of the implementation see CK contract source code - functions _breedWith(act as commit) and giveBirth + geneScience....


2

found it out myself, i multiplied all percentages by 10000 so they wouldnt be rounded down to 0.


2

No, I don't know how you imagined this, but as long as a user has the private key the ETH still on the account Nothing can stop him from spending his ETH. So whatever you do, locking ETH can only happen if ETH is transferred, be it to an escrow contract or maybe an off-chain multisig EOA.


1

Because the number needs to be hidden from other players. If the amount they sent in was equal to their number, then anyone could just read the transactions and take advantage of that fact.


1

If a miner throws away a block, they also throw away their reward. The economical incentive would need to be really high for them to discard a block like that. But that wouldn't help anyway with Oraclize - they send the data to the blockchain and some miner mines it anyway. I guess you can also ask for an array of numbers from Oraclize, but really can't ...


1

As you have correctly pointed out, in general, you can't transmit secrets in the open because they will quickly become public. I'm going to set aside the question of randomness source because that is, in itself, a complex puzzle. Also, the question of miners disregarding transactions that make them lose the game is probably addressed more directly at the ...


1

Just a update to this question, but this time it use a technique call verifiable delay function (vdf). It was built based upon time lock puzzle invented by Ronald L Rivest et al. The core idea behind is that if you can't calculate the result in a set amount of time, then the result is pseudo random. So with that in mind, vdf is a function which take in an ...


1

You need to use a third party to generate randomness. Contract accounts only perform an operation when instructed to do so by an Externally Owned Account. So it is not possible for a Contract account to be performing native operations like random number generation or API calls – it can do these things only if prompted by an Externally Owned Account. This is ...


1

Try the following algorithm to prevent cheating. The idea is to use hash of a block but the block number is not known for miners/participants and organizers to prevent cheating. On start organizer defines a random uint64 - key number to be used in the winner random number calculation. The uint number is big enough and known to organizer only on start. ...


1

Another way to generate random numbers could be to distribute various sources of randomness into the platform to seed the winning ticket. For instance we could use the cents of the closing prices of every stock traded in the main stock exchanges in the world. It would be nearly impossible to make all the stock exchanges work together to tamper the lotto. ...


Only top voted, non community-wiki answers of a minimum length are eligible