Author Topic: Bitshares Play FAQ  (Read 12532 times)

0 Members and 1 Guest are viewing this topic.

Offline logxing

BTS Account:logxing

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
                                                           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.
« Last Edit: April 02, 2014, 01:35:32 pm by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline logxing

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).
BTS Account:logxing

Offline logxing

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 out
means
              ^                                                                                                    ^
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---------------------------------------------------------->

BTS Account:logxing

Offline Stan

  • Hero Member
  • *****
  • Posts: 2908
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BitShares: Stan
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.
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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.
« Last Edit: April 02, 2014, 11:43:36 am by HackFisher »
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
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.

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.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline logxing

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...
BTS Account:logxing

Offline Overthetop

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 .

 :)
« Last Edit: April 02, 2014, 10:02:37 am by Overthetop »
个人微博账号: Overthetop_万里晴空
“块链创新与创业”交流群: 330378613

Offline logxing

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

Offline Overthetop

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.



« Last Edit: April 02, 2014, 09:49:42 am by Overthetop »
个人微博账号: Overthetop_万里晴空
“块链创新与创业”交流群: 330378613

Offline logxing

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.
« Last Edit: April 02, 2014, 09:46:17 am by logxing »
BTS Account:logxing

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
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.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
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.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
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.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu