Understood :D

Quote from: logxing on April 02, 2014, 01:11:23 PM
                                                           minerB can observer result before distribute it. So he can select another result which he prefer.

---------------------------------------------Time Line---------------------------------------------------------->

When minerB are going to re-select another result rather than distribute it, he are losing competition advantage to other miners. The process before observe the result takes time because POW are introduced.  This is what I mean economic impossible, and POW reduced the miner's influence to the result, time spent is the point.

And try result collision is difficult in a probability space of > 476127 (to get third-prized of double color lottory), given that the miner have maximum to 10x time before other miners have the block for distribution, the possibility is still very low < 1/47612.

If  the "future events" is determined by single person, this random has this problem.
So I think the key point is finally determined by single person(minerB).

Quote from: HackFisher on April 02, 2014, 11:26:57 AM

Quote from: logxing on April 02, 2014, 10:47:16 AM

Quote from: Overthetop on April 02, 2014, 10:00:23 AM
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .

:)

The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...

There are future events which are hard/impossible to predict("calculated out" in your words), so they are random to the observers before it happen, but not be determined yet util happen time. They are determined and happen at the same time, can not be calculated before that, but right away being calculated (and no need to calculated) out the same time(because every one knows).

But in some cases, observers can predict the result by influencing the event that will happen, that the case of miner here being as observers. We can add difficulty to the influence process to make their relation more independent, or economic impossible.

So I think future event is still a good option. But if the random event result is determined before it happen, and no one can know(calculate) it before ticket purchase, that would be great too. But the later case here is that, we can not guarantee that we can get it before deadline.

in short, the safest model:


be determined                                before                              it can be calculated outmeans
              ^                                                                                                    ^
miner generate block,
(Tx and the hash of seed)
                                           gather all random seeds,
                                                                                                everyone can observer result
---------------------------------------------Time Line---------------------------------------------------------->

Current model:


                                                   future events, be determined and everyone can observer result Immediately
              ^                                                                                            ^
minerA generate block(Tx),
                                                           minerB generate another block, the hash of this block determine result.
                                                           minerB can observer result before distribute it. So he can select another result which he prefer.
                                                           determine and observer at the same time

---------------------------------------------Time Line---------------------------------------------------------->

Quote from: gulu on April 02, 2014, 09:04:39 AM

Quote from: bytemaster on April 02, 2014, 08:34:23 AM
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery.  After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?   

So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.

Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network.  Then after the designated drawing block all members of the BOD reveal their secret key.  The secrets are all hashed together along with the hash of one block header of the drawing block. 

With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known.  The only way to rig the drawing is for the BOD members to collude.   If even one member is honest and keeps their information secret then the others are SOL.

The more board members you have the harder it is for them to collude.   

You could go so far as to have every ticket purchase include its own secret.  Once the purchase window is over, everyone reveals their secrets.  The hash of everyones secrets becomes the winning number.   Because no valid transactions should ever be excluded from the block-chain for more than 1 or 2 rounds of the BOD we can safely assume that no one could know the random number generated in the end.

What do BOD and SOL stand for?

BOD = Board of Directors

If you don't recognize the other one, I guess you're just SOL.   :)

http://www.urbandictionary.com/define.php?term=S.O.L.

Quote from: logxing on April 02, 2014, 10:47:16 AM

Quote from: Overthetop on April 02, 2014, 10:00:23 AM
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .

:)

The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...

There are future events which are hard/impossible to predict("calculated out" in your words), so they are random to the observers before it happen, but not be determined yet util happen time. They are determined and happen at the same time, can not be calculated before that, but right away being calculated (and no need to calculated) out the same time(because every one knows).

But in some cases, observers can predict the result by influencing the event that will happen, that the case of miner here being as observers. We can add difficulty to the influence process to make their relation more independent, or economic impossible.

So I think future event is still a good option. But if the random event result is determined before it happen, and no one can know(calculate) it before ticket purchase, that would be great too. But the later case here is that, we can not guarantee that we can get it before deadline.

Quote from: bytemaster on April 02, 2014, 08:34:23 AM
With something like mining with heavy hash power applied you are more likely to profit by submitting the block than holding out hoping to win the lottery.  After all, what are the chances that you could find 2 blocks before the rest of the network finds 1 relative to your chances of winning with the block you found?   

So from my perspective a mining based approach creates a decentralized random factor that is probably good enough.

Let's say we have a pool operator with 30% of the hash power, betting heavily on a 50/50 event . . . discarding some blocks could be very profitable - this is the case I wanted to guard against with a generalized solution for provable fairness in decentralized games of chance.

Quote from: bytemaster on April 02, 2014, 08:34:23 AM
Without mining I could see something along the lines of each member of the BOD generating a secret random number in advance, revealing the hash of the network.  Then after the designated drawing block all members of the BOD reveal their secret key.  The secrets are all hashed together along with the hash of one block header of the drawing block. 

With this particular structure the BOD would be committing to their secrete numbers long before the hash of the drawing block could be known.  The only way to rig the drawing is for the BOD members to collude.   If even one member is honest and keeps their information secret then the others are SOL.

I agree - this would be better than a single benevolent entity. In addition, the block hash could be used, so that colluding members would also need mining power for an attack. I wonder how we'd proceed if one of the required trusted members stopped co-operating. Also it still leaves open a potential attack route . . . . better if there was none, but perhaps that is a technically impossible requirement.

Quote from: Overthetop on April 02, 2014, 10:00:23 AM
I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .

:)

The algorithm is public. The key is seeds.
We should make sure the result(the winning number) be determined before it can be calculated out.
Actually, we can do this if we use all of the secret numbers(or private keys) to determine the winning number.But this is hard...

I mean reading some old random data from other Dacs and using some future elements also ,and then ,hybriding all these data to make out the final random number .

:)

Future events of blockchain is not so random. It is all about miner :(

Quote from: HackFisher on April 01, 2014, 08:36:54 AM
Benevolent entity with a secret key (e.g. classic satoshi-Dice) has the chance to cheating by submitting selective transactions.

I would like to introduce future events (e.g. future block's info) as the feed for generating random number, to prevent the miners from collision attack, pow might be added to the generation process.

Your approach of funds/prizes management is simple and feasible, are the prizes awarded calculated in a deterministic way according to ticket sales? I prefer deterministic way to keep that the total supply can self-sustain.

Getting random elements from future events is a good idea.  :)

How about grab some random data from other DAC's block (BTC,LTC,NXT...) and hybrid the data  before making the random number?

I think it maybe impossible to be attacked or controlled by bad guys.

I think pow or economics motivation is not enough.
I hope it is safe by nature.

By the way:
public key->hash
private key->random secret number
will be simple.

BTW, I meant using the hash that satisfies hash target. Just take the hash itself as the lucky number, or hash of that hash. No Txs should be messed with the lucky number, since they are inherently controllable by miners.

Quote from: gulu on April 02, 2014, 09:28:25 AM
If the miner gets a non-trivial piece of the pot, there is really little motivation for him to select blocks. Say 0.1% of the win.

Here, the prerequisite is that we have distributed mining power. Then, whenever a miner finds a block, he is eager to publish it and make it propagate through the network as quickly as possible.

If the miner gets a non-trivial piece of the pot, there is really little motivation for him to select blocks. Say 0.1% of the win.