RNG using Block informations

[markm]

As soon as the current txs are confirmed (1), I need a provably fair 0-9 RNG.

Okay so tell the user the hash of the seed that you do know, ask them for a random seed they provide themselves (for example, the transaction number of the transaction in which they sent you some bitcoins), wait for the block to confirm, then whether they win or not tell them the actual seed you used, the one you previously told them the hash of.

Notice that even if they lose, they still need to know what seed you had chosen, the one you had told them the hash of, if they want proof of fairness.

If you don't want to publish the proof (the seed you chose) on a diceroll by diceroll basis you can use aggregates such as having each day's seeds-to-use already in files ready to use (more than enough for each day, way more in case you get unexpected amount of traffic) and after the day is over move that day's file to a place where the public can see it, and publish there too the bet by bet / diceroll by diceroll log of all the dicerolls so the public can match up first roll of the day to first seed you had scheduled for use that day, second roll to second seed etc.

Log to public could maybe publish live realtime what the hash of your seed is, what seed a user provided, and, when the block is confirmed, what the dice actually came up as. Then once the day is over, publish the actual file of seeds and enhance the day's log by appending each seed that was actually used to the log entry of the play it was used by.

If you want to spam losing bets to the blockchain you could encode the seed you used into the "you lost" spam as well as coding it into the "you won" payments so the player can see it is fair as soon as they know whether they won or lost.

-MarkM-

[Dabs]

@gmaxwell, so the merkle root hash is a bad idea? Well, the block hash doesn't seem so bad anymore then. But if you have a server seed as well, that makes 3 seeds in total which can be used in the hash or HMAC function.

1. Server Secret Seed
2. Block Hash or Merkle Root
3. Player or Client Seed

[TierNolan]

1. Server Secret Seed
2. Block Hash or Merkle Root
3. Player or Client Seed

Why not just use this system:

Player picks random number X
Server picks random number Y

Server sends hash(Y) to the player
Player sends hash(X) to the server

Player sends X to the server
Server sends Y to the player

Both compute (X XOR Y) and take the lowest digit.

Note: X and Y would be large numbers

That gets you a completely random number, as long as at least one of the server and the player wants it to be random.

[markm]

That gets you a completely random number, as long as at least one of the server and the player wants it to be random.

A protocol that allows non random results if both parties want it to would be awesome for money-laundering and bribes!

You could head off to the casino to collect your pre-determined paycheque, and by sheer luck, you win, that exact amount, and no one can prove it wasn't sheer luck!

Your protocol that I don't think quite provides that though. I wonder what protocol would...

Or wait, maybe yours does provide that! I figure its more useful/interesting to raise the question than to bother thinking whether yours does until after I post, so others can experience the joy of thinking too...

Though maybe the real answer is so obvious it doesn't really require any thought.

(Oh yeah? Then how come a few setences ago, back when "I don't think", I didn't necessarily type the right answer? Hmm. Maybe "I do think" would be a more useful general approach to problem-solving.)

I can guess now that legislators will prefer the "seeds to use file made in advance" to "invent a new seed on a per play/player basis on the spot" if only to make launderers have to keep very tight appointments to be sure they were in fact hitting the site precisely at the right point in the sequence of seed-use to get their payseed honoured.

-MarkM-

[Dabs]

It depends on how soon you need to create the new random numbers. Dice sites will not lose on purpose unless the owner does not want to pay his investors, which is a problem with all dice sites.

If you need the numbers instantly, you need to use a server secret to prevent players from choosing the results. If you need to be certain that either party can manipulate the results, you need to get the seed or secret from a disinterested third party and wait for those numbers.

You can use other site secrets, the next block hash, real life lotto numbers... They all have time schedules. Other sites usually take a day. Some have one every hour. Real life lottos you can be assured will not be manipulated, otherwise someone will use that to buy the winning ticket.

[jeezy]

Again guys, I don't want to use any server secret, client/server seed technique and no external rng. This topic is specificly for using the information we got on the blockchain to generate solid & transparent random numbers. I think I got quiet a good idea for my project now, thanks.

[deepceleron]

I previously published a method using the block hash as a pseudo-random number generator for raffle ticket picking. The block hash is quite random: the only way of manipulating future block hashes is to be a significant miner and discard winning block hashes if they don't meet a criteria, which gives you even less chance of influence than your hashrate would indicate in addition to discarding 50 25 BTCs:

http://we.lovebitco.in/raffle.html

Hey guys,

okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1).

My approach so far looks like this:

Code:

hmac_sha512($blockhash, $nonce)

Using a 512 bit hash gives the illusion that there is more entropy than there is.

The block hash can be considered as a random number generator, with an even distribution of results between 0 and the current difficulty target, currently 0000000000000031679C00000000000000000000000000000000000000000000. That's currently less than 198 bits of entropy. It would be more appropriate to re-hash the block hash with a secure 160 bit algorithm such as RIPEMD-160 just to be clear in algorithms that that is the depth of the randomness.

A block hash not the best secret for a gambling site, as it not a secret, and your salting method may be discoverable. It is good when a future random number pick will determine a winner and the picking method needs to be verifiable by all.

[jeezy]

I previously published a method using the block hash as a pseudo-random number generator for raffle ticket picking. The block hash is quite random: the only way of manipulating future block hashes is to be a significant miner and discard winning block hashes if they don't meet a criteria, which gives you even less chance of influence than your hashrate would indicate in addition to discarding 50 BTCs:

http://we.lovebitco.in/raffle.html

Hey guys,

okay, first of all I'm new to this crypto stuff and I know the issue of "Provably Fair" has been discussed over and over again. Yet I haven't quiet found any definite answer to my approach. What I want to do is make the RNG more transparent by taking the information of the next/current block found (txconf=1).

My approach so far looks like this:

Code:

hmac_sha512($blockhash, $nonce)

Using a 512 bit hash gives the illusion that there is more entropy than there is.

The block hash can be considered as a random number generator, with an even distribution of results between 0 and the current difficulty target, currently 0000000000000031679C00000000000000000000000000000000000000000000. That's currently less than 198 bits of entropy. It would be more appropriate to re-hash the block hash with a secure 160 bit algorithm such as RIPEMD-160 just to be clear in algorithms that that is the depth of the randomness.

A block hash not the best secret for a gambling site, as it not a secret, and your salting method may be discoverable. It is good when a future random number pick will determine a winner and the picking method needs to be verifiable by all.

Yeah, I've seen your approach last week and find it very interesting for the idea I got. It's basically exactly what I need. Also I might rainbow the result with the txs that went into the raffle. This is both transparent for everyone and adds even more entropy.