7

Since you're using the blockhash as your random number seed, this is actually a pseudo-random implementation. See this post for more information. To do this correctly, you'd want a decentralized oracle with provably random verification. A Chainlink VRF is your answer. Here is a kovan implementation of your request, you can deploy it to remix with this link. ...


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("...


6

The organizer can cheat the system by attempting many different addresses, which, when added to your formula Key number + address1 + address2 ... + addressN % 255 as the last address and getting the hash of the block, make this address the winner. You can think about it this way: If your system is secure, there is no way to cheat the system. If there is ...


6

we want to use the block hash of some block in the future as a seed for the random generator. I think using a future block hash is generally considered "safe". (This article discusses using future block hashes, though on-chain inside contracts. I can't see how off-chain would be any less safe: https://blog.positive.com/predicting-random-numbers-in-...


5

You have to do it without relying on anything that triggers at that moment. You use the block.number to decide if bets are allowed. function isOpen() { return(block.number <= deadline); } function bet( ... { require(isOpen()); ... } You determine a winner retroactively. function didIWin( ... { if(!isOpen()) return false; return winner() ==...


5

What you want is a random number within a range of 900 options. So do this: function random() internal returns (uint) { uint randomnumber = uint(keccak256(abi.encodePacked(now, msg.sender, nonce))) % 900; randomnumber = randomnumber + 100; nonce++; return randomnumber; } Basically you get a number from 0 - 899, and then add 100 to match ...


5

A common problem in the traditional web2 art and trading card world is the transparency of randomness and scarcity. If you buy a trading card, like a Pokémon card for example, you have no way of knowing how rare it really is without talking to the company that printed it. There is a centralized component to the scarcity of the card. They could have printed ...


4

You can use an incrementing nonce each time a number is generated. This would have a large effect on the hash output. Random 0-100 Example: contract Random { uint nonce; function random() internal returns (uint) { uint random = uint(keccak256(now, msg.sender, nonce)) % 100; nonce++; return random; } function getRandom() ...


4

There is a util that can create "cryptographically strong pseudo-random HEX strings from a given byte size." You could then convert this to a number. web3.utils.randomHex(size) --> documentation Per the github web3js documentation the library frozeman/random is used to generate randomness


3

It's a bit tough to explain completely. But there's an oraclize contract on the main net and testnets (Kovan, Rinkeby, Ropsten..) which you can import and use it's functions. Then after your queries are done, a 3rd party (Oraclize.it) provides you the results. They also give result data encryption possibilities and some kind of proofs that allow them to ...


3

Generally a working laptop will have sufficient entropy, especially when it's been running for a while, as it has lots of places to get it from, such as you typing on your keyboard and moving the mouse. You're more likely to have trouble with freshly-booted servers, and particularly VMs. On a general-purpose laptop you should probably be more worried about ...


3

Yes and no. There's always a bit of risk involved with using block hashes as a source of entropy--if the value of the bet is far greater than a block reward, miners can potentially game the system a little bit, by simply discarding a block if they mine it and it doesn't give them a favorable number. The other complication is that you have to ensure that ...


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.


3

So your solution of discarding the numbers is known as rejection sampling and is indeed the way to solve your issue for your given inputs. As you've also noticed, there is a cost associated with this due to the nature of Oraclize. If you prefer not to have that extra cost, then your only other option is to remove this biasing affect of the modulo operation ...


2

There's no such thing as Math.random on the Ethereum blockchain. If there was, miners could play the system and peak into Math.random before broadcasting a block. If broadcasting the block means they lose 100,000 ETH, they just wont broadcast it and they'll try to make a block that makes them win. They could easily cheat the system. The most common solution ...


2

You can't use Math.random because Ethereum has no Math.random. Ethereum has no Math.random because all calculations have to be deterministic so they can be validated by different nodes on the network, which doesn't work if they're all coming up with different numbers.


2

See this discussion for the issue of using random numbers in general: How can I securely generate a random number in my smart contract? This describes a number of approaches including commit-and-reveal, which is the most secure approach, but has some practical downsides. There are some circumstances where it may be appropriate to use block.blockhash. It's ...


2

Randomness is very difficult in Ethereum, but how perfect you need it really depends on your goals. If aren't storing tons of value and 'almost' perfect randomness works, then your code works great. If you want to get better, there are discussions all over the internet on it, but no one solution has really emerged as the standard. Here's one discussion in ...


2

But, then, that would mean an user could create a contract that reads that nonce and only calls generateTreasure if it provides a good treasure with said block hash! Is that correct? Correct. The variables needed to create the random number will be either available directly to an evil contract (eg your contract can read the block hash, but my evil contract ...


2

This is not secure! A person can wait to publish the transaction with their bet after they saw a block with a hash which would make them win! They could use a high transaction fee to get a good chance their bet would be included in the next block, at which point they would win. A random number generator for a lottery should of course always use a random ...


2

Block hashes are not a reliable source of randomness in situations where the miner that has mined a block at that height, or a subsequent miner with the choice of whether to mine on top of that block, has an incentive to try to alter the result. For example, if you're making a lottery, a miner can make a bet, mine the block whose hash will settle it, and ...


2

There are two things to think about with this sort of approach: Consider the Sybil attack where the miner and the "house" are the same entity (or otherwise colluding). Consider the possibility of the "house" refusing to reveal the seed. The latter can probably be taken care of via some deposit that's forfeited (and distributed to other participants?) if ...


2

I believe he's referring to this: https://www.gwern.net/Self-decrypting-files. The idea is similar to commit/reveal schemes: Alice picks a random number, hashes it, and shares the hash with Bob. Bob shares a random number with Alice. Alice reveals her random number. (Bob can check that this is the correct number, since he knows its hash already.) Both ...


2

"Creating" an account doesn't do anything with Ethereum at all. (You could do it completely offline, even by hand on paper.) An account is just a private key, which is essentially a big random number. Some math converts the private key to a public key, and then some more math converts that public key to an address. Now to answer the individual questions: ...


2

You mentioned you are using Oraclize. They provide not only random number querying, but allows you also to perform requests to the outer network and receive parsed json. I think it is best option for your case.


2

Yes they can Are timestamps (now, block.timestamp) reliable? This depends on what you mean by “reliable”. In general, they are supplied by miners and are therefore vulnerable. (...) Never use now or block.hash as a source of randomness, unless you know what you are doing! doc There is more reliable way to obtain randomness with an Oracle. But instead of ...


2

There is a fundamental problem with this approach: the concept of "contract that will yield...after a period of time". All actions in smart contracts are triggered with a transaction. Contracts never do anything "by themselves". So somebody has to send a transaction a point X in time to the contract and then the contract can check "is the current block above ...


2

Yes, someone can see private values. Private simply tells contracts what they can and cannot read. People can extract the data from the private value. Please see this thread. And also in the api for solidity it states: "Everything you use in a smart contract is publicly visible, even local variables and state variables marked private."


2

No, a miner will know the current block.difficulty for each block, in real time, at no cost to them. That means whenever reward < x, one can know with 100% certainty what the value of your "random" number will be. So your random number isn't random at all.


2

As hinted at by Ismael in the comments your question is mostly about the algorithm and is largely answered in the linked stackoverflow question. However the part which is special for Solidity (and Ethereum) is the randomness part. Randomness in deterministic smart contracts is a tough question - there are good and bad solutions for it. So once you decide ...


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