Author Topic: Bitshares Play FAQ  (Read 12438 times)

0 Members and 1 Guest are viewing this topic.

Offline gulu

  • Full Member
  • ***
  • Posts: 121
    • View Profile
I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.

Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).

How about that? More details need further discuss.
The owners of Txs at block 500 have the option the send their private keys or not, because they can always choose to take their clients offline. But it's hard to really control the final results. When one owner sees some results he likes, other owners will update their keys and alter the results. Then, I will plant lots of Txs at block 500 as my ammunition. When everybody has exhausted their ammo, I am the only one shooting and selecting results.
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline logxing

En...maybe we need all of the privates keys(difficult), otherwise miner block 510 still can select *private key* to do attack...
BTS Account:logxing

Offline logxing

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.

Yes, we think alike :D
BTS Account:logxing

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile

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.

Yes, @logxing and I had a discussion about a similar solution this afternoon.

I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.

Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).

How about that? More details need further discuss.
Each user generate a random public_key together with ticket purchase, and after the ticket transactions are valid, user then publish their private key relate to the pub_key. DAC (miners?) use this private key to generate random numbers. I think This approach is quite similar to FreeTrade's meaning of provable distributed. Random number generated in this way is more reliable, I think, even though it introduce more complicate design:

1. How to select the pub_keys from distributed entities' transactions in this block, we could not identify entity behind address?
2. How to collect enough/required private keys before deadline?

The simplest way would be to use all the private keys already received before deadline, but the transactions to publish this private keys also need to be mined, in another word, has the chance to be filtered by bad miners.
« Last Edit: April 02, 2014, 09:15:57 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 gulu

  • Full Member
  • ***
  • Posts: 121
    • 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.

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?
BTC: 1FRsgcQELHKFY2VMFosBnyBaNxZgS4wj7x
PTS: Pf9yDYUknXShepu6YjwSEpMvm1ewNQLNgE
BTSX: gulu

Offline logxing

I have an idea and today I had discussed it with hackfisher.
Here is it:
1.Every Tx has a parameter which is a random public key(e.g. ECDSA).
2.Miner will pack these Txs and generate a new block(e.g. at the 500th block).
3.When block 505 were generated, the DAC client will send the private key generated in step 1 automatically.(505 is just for safe, make sure not to send private key too early)
4.These private keys will also be pack in block 506-510.
4.When block 511 were generated, new private key for block 500 will not be accepted any more.These private keys for block 500(recorded in block 506-510) will be the seeds of the random number generator, using for determine the result of block 500.

Thus, when miner generate a block, they can not predict the result by select Tx, because they don't know the seeds(private keys).The result of block 500 is related with Txs in block 500 and the private key for block 500 recorded in block 506-510(generally ,not all private keys of Txs in block 500).

How about that? More details need further discuss.
BTS Account:logxing

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
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
>I came to the conclusion it would either need to rely on existing lottery draws, or have a benevolent entity with a secret key.

(By benevolent entity I mean someone who wouldn't cheat - but the market would punish that flaw because the potential to cheat would be there)

Maybe Dan has some ideas on provable distributed fairness - I thought long and hard on it over several weeks and couldn't solve it.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline HackFisher

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

Now miners, or more likely, pool admins, have a chance of cheating by selective discarding of unfavourable blocks.

Solving this problem of provable distributed randomness is key.

You are right, even with pow, miners still have chances to attack, the randomness would be better to be generated out of control of any entity, I'm thinking your approach of provable distributed randomness.
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
Benevolent entity with a secret key (e.g. classic satoshi-Dice) has the chance to cheating by submitting selective transactions.

Yes, this is why it is far from ideal - maybe multiple entities with secret keys to generate a random number.

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.

Now miners, or more likely, pool admins, have a chance of cheating by selective discarding of unfavourable blocks.

Solving this problem of provable distributed randomness is key.

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.

I prefer fixed-odds, with a house edge and let probability gradually reduce coin supply. Think more like Keno that a proper lottery.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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.
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
I think a properly implemented Lottery DAC is a killer idea. Maybe even better than a bank.

I was giving serious consideration to launching a Lotto DAC about a month ago and the chief problem I couldn't solve elegantly was how to do fair random draws - provable decentralized fairness. I came to the conclusion it would either need to rely on existing lottery draws, or have a benevolent entity with a secret key. Have you come up with a better solution?

The approach I would recommend is to destroy funds spent on tickets/bets, with maybe a 1% fee to ticket processors (miners) . . awarding all prizes from coinbase. Unlimited prize size. Profits are generated through deflation as money supply is gradually reduced.

Also there's a guy working on a cryptocoin casino - on bitcointalk, don't think he's aware of the DAC concept, but is working on something that is essentially the same.
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
This thread is to summary the frequent asked questions in the forum.

FAQ:
1. how to do fair random draws?
To be summarized, can have a look of details discussion from #2 to #27.

2. Will Play DAC be with lot of rules and share one chain?
Or, will Bitshare Play allow many different kinds of Play DACs been created on  the same network?

To be summarized.

3. What's the role of play shares in Bitshares Play?
Be simple, people own play shares to play the game, or act as DAC owners, or for purpose of mining, they can select whatever role they like. To be summarized

4. Where to get the White Paper?
https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit?usp=sharing

« Last Edit: August 12, 2014, 12:32:58 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.