RNG using Block informations

[jeezy]

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)

Since I think the nonce is fairly random and could never be guessed, using it as the secret would give me quiet a strong random variable which is also transparent at the same time. Now I read a lot of stuff about blockhashes tending towards lower numbers, so I should add something to the hash to make it even more random.

Would you think adding the blocktime would make it even more random or isnt necessary:

Code:

hmac_sha512($blockhash, $nonce+$blocktime)

Cheers

[fpgaminer]

Could you describe a specific use case?  i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.

Since I think the nonce is fairly random

Are you referring to the nonce in the block header?  If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased.

[Dabs]

HMAC is usually used where the first argument is secret, and the "message" is the second argument.

You can use the blockhash, or the merkle root hash, both are random and practically unpredictable. The nonce for most gaming sites are usually incrementing, unless you are talking about the blockchain nonce used for that particular block.

The block time would be optional and not needed.

What is your intended purpose? Some game? You mention "Provably Fair". I personally like this kind of topic.

If you use public information for your RNG, then the results are predictable after the fact. This is good for games where the results are needed later, such as raffles or lottos. Not so much for games where you want the results now, such as dice games.

[jeezy]

Could you describe a specific use case?  i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.

You could for instance take the first decimal via pregmatch and use it as a 0-9 RNG. My test script that I ran hundred of times (1 billion iterations each) verifies that it's evenly distributed 0-9 and no number is in favor.

Since I think the nonce is fairly random

Are you referring to the nonce in the block header?  If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased.

Okay, how about taking the exact blocksize as the second secret then? That should be unguessable before the block gets found/generated?

[jeezy]

HMAC is usually used where the first argument is secret, and the "message" is the second argument.

You can use the blockhash, or the merkle root hash, both are random and practically unpredictable. The nonce for most gaming sites are usually incrementing, unless you are talking about the blockchain nonce used for that particular block.

The block time would be optional and not needed.

What is your intended purpose? Some game? You mention "Provably Fair". I personally like this kind of topic.

If you use public information for your RNG, then the results are predictable after the fact. This is good for games where the results are needed later, such as raffles or lottos. Not so much for games where you want the results now, such as dice games.

Yeah, in PHP it's the other way around  http://www.php.net/manual/en/function.hash-hmac.php

So I could just hmac the blochhash and merkleroot and would get a non-predictable hash. That's good to know! I will run a couple of tests with merkleroots then.

[Remember remember the 5th of November]

Could you describe a specific use case?  i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.

You could for instance take the first decimal via pregmatch and use it as a 0-9 RNG. My test script that I ran hundred of times (1 billion iterations each) verifies that it's evenly distributed 0-9 and no number is in favor.

Since I think the nonce is fairly random

Are you referring to the nonce in the block header?  If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased.

Okay, how about taking the exact blocksize as the second secret then? That should be unguessable before the block gets found/generated?

Then how would you know it beforehand to use it yourself?

[markm]

Are you familiar with the usual techniques existing sites use to accomplish "provably fair" ?

If so what is it about their method(s) that make them unsuitable for your use-case (and thus requires you to re-invent their apparently not so elegant after-all wheel)?

-MarkM-

[jeezy]

Could you describe a specific use case?  i'm having a hard time imaging what the hmac_sha512 of a blockhash could be used for.

You could for instance take the first decimal via pregmatch and use it as a 0-9 RNG. My test script that I ran hundred of times (1 billion iterations each) verifies that it's evenly distributed 0-9 and no number is in favor.

Since I think the nonce is fairly random

Are you referring to the nonce in the block header?  If so, it's not necessarily random (it's possible to mine with nonce set to a constant, for example), and it's certainly quite biased.

Okay, how about taking the exact blocksize as the second secret then? That should be unguessable before the block gets found/generated?

Then how would you know it beforehand to use it yourself?

Not beforehand, the second a new block is found the information is there and I can use it for 1 conf txs.

Are you familiar with the usual techniques existing sites use to accomplish "provably fair" ?

If so what is it about their method(s) that make them unsuitable for your use-case (and thus requires you to re-invent their apparently not so elegant after-all wheel)?

I just want it to be a full transparent RNG layer on top of the block chain.

[markm]

I just want it to be a full transparent RNG layer on top of the block chain.

And the usual method does not qualify?

(I had hoped for a yes or no, with more info following in the case of yes.)

So maybe even more clarity is missing... where does $nonce come from? Your pre-imaged scheduled list of nonces-to-be-used-soon or do you mean the nonce a miner put into the blockchain?

(Not sure if pre-imaged is correct term; i mean the file of nonces / seeds / random values concealed onoff your site whose hash is shown all users before they bet, then revealed once it has been consumed so later everyone can see that the seeds to be used were in deed already determined in advance.)

-MarkM-

[jeezy]

I just want it to be a full transparent RNG layer on top of the block chain.

And the usual method does not qualify?

(I had hoped for a yes or no, with more info following in the case of yes.)

In my oppinion the second the site operator knows more about the possible outcome than the user, they got the advantage. If that advantage is relevant for the RNG or even gets actively exploited doesn't matter, because the principle is the same. I just want my approach to be as transparent, seamless & integrated as possible, using the given bitcoin protocol.

[markm]

So basically all players and the platform know the state of the RNG in advance and then it is up to miners whether or not the next block produces a win or not?

If that is the case, you could just plug in the hash of the block as both inputs to the RNG (both is in the document to digest and the nonce to anti-rainbow the result) couldn't you?

Its no longer a random number generator though if you do that, rather, it is a war among miners to see whether any of them can come up with a winning block, isn't it?

In the usual/customary means of accomplishing "provably fair" miners have no say as they only provide one input, the other is already pre-determined in advance (provable after the fact that is was in fact pre-determined) and not known to miners.

It sounds like you are calling for a hashpower war, like the ancient times "God's Acre"* concept that God will see to it that the right answer will be revealed on the battlefield.

God does not play dice aka God's Acre is not a cryptologically random process.

So to get "provably random", first a true prophet of the true God records a prophetic file containing a list of all the nonces that will be used over the next however many rolls of the dice, then the miners do their thing without any knowledge of the nonces, or something like that. I gotta sleep again I think as this is starting to get mind-boggling again. (How do they prove they didn't reveal to the miner(s) in advance what the prophet put in that file? Hmm.) Hope someone else can help I just ran out of steam. Its the fact the prophet was right as to what the nonce would be that proves it all, somehow, I do recall that much I think.

Prophet: "the hash of today's nonces-file is weg04ee-0y"

At end of day the file of nonces is published, lo and behold, the prophet was right as to what that file's hash is!

Bah, I now see, I think, why you prefer that all miners, not only site-insiders, know the nonce in advance. (The usual method doesn't seem elegant at all to me right now. The holy file of nonces-to-be-used seems merely a cheatsheet the site insiders can crib from.)

-MarkM-

* Wikipedia doesn't mention God's Acre being a term for a battlefield, it has it as a graveyard. Try googling for God's acre game, as I got the term in my youth from a tabletop miniatures battles rule book, which is where I also got the idea it was a term used in olden times. As I use it here, I mean a battlefield as in God will determine the outcome when the crusaders and infidels meet to "hash it out".

[jeezy]

words

Not sure if this is a troll or not but I will say this much: All I wanted to know is if the blockhash is totally random and can't possibly be known in advance, so I can use it as a transparent RNG seed, one guy said it sure is, so this issue is settled then.

[gmaxwell]

Not sure if this is a troll or not but I will say this much: All I wanted to know is if the blockhash is totally random and can't possibly be known in advance, so I can use it as a transparent RNG seed, one guy said it sure is, so this issue is settled then.

Too bad, because markm gave you a nice answer.

Miners can potentially select the block hash to meet some characteristic. They'd do so at great cost, but that being a viable attack depends on what exactly you're using this for, what information is available to miners, etc.

[Dabs]

How much time do you need? A block is about 10 minutes. If you can wait a day, you could use other site secrets as well. You can even use random.org.

My lotto uses 7 secrets. 1 only I know, 5 belonging to other sites, and 1 from atmospheric noise which no one knows. I concatenate them all together then use that to hash my tickets. It can't get any more provably fair than that.

I say, use 1 secret of your own + the block hash or the merkle root hash of the next block and not even the miners would be able to reasonably manipulate it. This is exactly what PeerBet does, and almost the same method of blockchain based games like SatoshiDice.

[gmaxwell]

merkle root hash of the next block

You use the merkle root of the next block??? Where is this site of yours?  Daddy needs a new pair of shoes!

[Dabs]

I don't have one yet, but I think using the merkle root is better than the block hash, don't you think?

Every transaction has a hash associated with it. In a block, all of the transaction hashes in the block are themselves hashed (sometimes several times -- the exact process is complex), and the result is the Merkle root. In other words, the Merkle root is the hash of all the hashes of all the transactions in the block. The Merkle root is included in the block header.

Clarification, I suggest using the merkle root of the next block as a means to determine the winner of your game or as source of unpredictable random numbers which can be verified later. Players have to wait until the next block. I'm thinking you misunderstood what I said and I am predicting the merkle root of a future block, which is impossible.

[gmaxwell]

I don't have one yet, but I think using the merkle root is better than the block hash, don't you think?

I hope you're building this service with your own money... because you're going to be broke if you think this is okay.

Miners can iterate over their merkle root for practically free. Your security would come entirely from how difficult it would be for an attacker to convince miners to run special block template creation software that picks merkle roots to their liking.. The attacker doesn't even need pool cooperation, and they could setup a parallel secondary pool where people submit shares with suitable roots and pay them for it. (e.g. users install a patched cgminer on their miners and start getting paid for producing work that attempts to rig your game).


 

[markm]

Right.

So if you must use God's Acre, that is, a block...

You might as well use the whole block (aka the whole acre).

Any bit of it they change is still an iteration with a bit changed, just like if they'd changed a bit of the nonce or extranonce.

But why do you need to use blocks at all?

Depending on quite what you are trying to do, might it work just as well to tell the player "I have made up a seed whose hash is X, please enter a seed you want to use, then I will reveal my seed, you can hash it and see it does indeed hash as I claimed, so you know I didn't change my seed after seeing yours" ?

-MarkM-

EDIT: I went back up-thread to clarify my use of the term God's Acre as wikipedia doesn't mention it meaning battlefield they say graveyard.

[jeezy]

Miners can potentially select the block hash to meet some characteristic. They'd do so at great cost, but that being a viable attack depends on what exactly you're using this for, what information is available to miners, etc.

As soon as the current txs are confirmed (1), I need a provably fair 0-9 RNG. So my idea was to hmac the blockhash + something else (it can't be anything I control or know) and take the first digit the hmac produces and thats our winning number. Maybe I should just take the current blockhash (conf=1) + something of the last block (size/nonce/merkle/whatever) (conf=2). That would mean that miners need to manipulate 2 blocks in a row to rig the game.

[gmaxwell]

That would mean that miners need to manipulate 2 blocks in a row to rig the game.

No they wouldn't. Not unless there is state they don't know.