Bitshares Lotto rule deployment, script code being part of blockchain?

[gamey]

Ahh well that is very good to know.  Good good good!  I was tired last night when I read that.  I'm awaiting lottodac and saw all this suggested complexity.  It didn't make sense at all, but I should have had more faith!

Still,  I would just suggest you parameterize your lottery and not try to go with some form of an interpreted script.  I don't understand why you think you need a script ?  What featureset do you expect ?  What are some use cases that would require interpreted code pulled off the blockchain ?

Part of my confusion is that so much of this is in the Charity forum.  I was assuming it would all go under gaming.  Which is what people in the legal gambling industry call gambling.  "gaming".  I'll reread the posts in here to see what is going on.

Keep up the good work Hackfisher and sorry for being a doubter !

[HackFisher]

I'd like to just see a version released with hardcoded rules. If you are having a hard time moving forward, adding complexity will not help.

If you want reconfigurable rules, do it via parameters.  Not code.  Interpreting code etc just seems like a big rabbit hole + security issues.

Break it down into parameters that lotterys have.  I'll put a few off the top of my head.

1. Period of drawing.
  a) By block count
      arg1 - block count
  b) By ticket purchase amount
      arg2 - ticket amount
  c) Both a & b but whichever is hit first.

2. Payouts
  a) All prize pool is paid per drawing
      args[] - payout info encoding
  b) Cumulative jackpot
      ....


For payouts let me go through an example.
X is the number of balls in the pool of balls.
Y is how many balls people choose for their lotto pick and how many balls are chosen to select a winner. (Always same value)

So list payout share for choosing Y balls, payout share for Y-1 balls ........ payout shares for 1 ball

Example -
X = 50, Y = 5  (Actually X doesnt matter, except when figuring out your payout schedule)
'
(*Note, I am using shares in a manner different from bitshares/stock)

So Y = 10000 shares, Y-1 = 100 shares, Y-2 = 10 shares Y-3 = 5 shares Y-4 = 1 shares
So if prize is not cumulative you add up the total shares and pay them out proportionally.
So the 5 balls drawn composing Y are 1,2,4,10,20 (winning #s)
One person chooses 3,2,4,10,20 so they get the Y-1 value (4/5 balls) or 100 shares.
2 people chose 10,X,X,X,X so they get Y-4 value of 1 share.  (Only their 10 matched)
So that is 100 + 2 * 1 = 102 shares..  So person who hit 4 numbers get 100/102 of the prize pool.
The 2 people who hit 1 number get 1/102.  Of course some portion goes to the lotto dac too.

If you have cumulative jackpot option then perhaps the payout vector is different and only Y through Y-2 counts, but never give Y-1 or Y-2 all of the prize pool and have the rest of the pool roll over until someone hits all Y balls.

This sort of thing allows you to give all manner of lotteries without code.  Lotteries are really simple.  There should be no need for interpreting code off blockchain.  Please. 

Enforce sanity.  Each payout with less matching balls is paid less.  Put some limits on the values and you have a pretty simple ruleset which can probably closely emulate the vast majority of lotteries.

Hope this makes sense.  I'm tired. 

How you will have competing lotteries I am not sure, but I just can't imagine interpreting code in a VM to be anything but a huge headache with little upside.  The complexity of lottos does not begin to justify that approach.

gamey, as metioned in another lotto staus update thread, this is the idea for the future after it is mature or I could solve all the design issues, not for now or short term.

Take it easy.

来自我的 GT-N7100 上的 Tapatalk

[gamey]

I'd like to just see a version released with hardcoded rules. If you are having a hard time moving forward, adding complexity will not help.

If you want reconfigurable rules, do it via parameters.  Not code.  Interpreting code etc just seems like a big rabbit hole + security issues.

Break it down into parameters that lotterys have.  I'll put a few off the top of my head.

1. Period of drawing.
  a) By block count
      arg1 - block count
  b) By ticket purchase amount
      arg2 - ticket amount
  c) Both a & b but whichever is hit first.

2. Payouts
  a) All prize pool is paid per drawing
      args[] - payout info encoding
  b) Cumulative jackpot
      ....


For payouts let me go through an example.
X is the number of balls in the pool of balls.
Y is how many balls people choose for their lotto pick and how many balls are chosen to select a winner. (Always same value)

So list payout share for choosing Y balls, payout share for Y-1 balls ........ payout shares for 1 ball

Example -
X = 50, Y = 5  (Actually X doesnt matter, except when figuring out your payout schedule)
'
(*Note, I am using shares in a manner different from bitshares/stock)

So Y = 10000 shares, Y-1 = 100 shares, Y-2 = 10 shares Y-3 = 5 shares Y-4 = 1 shares
So if prize is not cumulative you add up the total shares and pay them out proportionally.
So the 5 balls drawn composing Y are 1,2,4,10,20 (winning #s)
One person chooses 3,2,4,10,20 so they get the Y-1 value (4/5 balls) or 100 shares.
2 people chose 10,X,X,X,X so they get Y-4 value of 1 share.  (Only their 10 matched)
So that is 100 + 2 * 1 = 102 shares..  So person who hit 4 numbers get 100/102 of the prize pool.
The 2 people who hit 1 number get 1/102.  Of course some portion goes to the lotto dac too.

If you have cumulative jackpot option then perhaps the payout vector is different and only Y through Y-2 counts, but never give Y-1 or Y-2 all of the prize pool and have the rest of the pool roll over until someone hits all Y balls.

This sort of thing allows you to give all manner of lotteries without code.  Lotteries are really simple.  There should be no need for interpreting code off blockchain.  Please. 

Enforce sanity.  Each payout with less matching balls is paid less.  Put some limits on the values and you have a pretty simple ruleset which can probably closely emulate the vast majority of lotteries.

Hope this makes sense.  I'm tired. 

How you will have competing lotteries I am not sure, but I just can't imagine interpreting code in a VM to be anything but a huge headache with little upside.  The complexity of lottos does not begin to justify that approach.

[XHC]

That's very good!

Actually, I'm conceiving something similar recently.
Here's my points,

1. Everyone can issue new rules just like transactions.

2. The new rules would be validated by the node who would generate the next block such as a delegate.

3. People vote on the rules proposed.

4. The rules with votes exceeding a some threshold would be voted by all the delegate to determing wheter to accept the rules.

5. The rules accpeted would be the new rules added to the original rule logic of the DAC

6. All the nodes in the DAC should compute based on the refreshed rules.

Any comment is welcomed.

[HackFisher]

I think we don't need to validating the code by delegate.
Just like create an asset don't need to validate.

market will validate the code.
some fee can pay to the address who publish the code.
after publish, he will introduce in the forum or whereever.
others can decide to play or not.
finally, market will give the player  good choice

Yes, that's a good point, but we are still facing challenges like computation steps cost, which could be used to attack the client, I think etherum's gas fee could be a good approach to solve this.

Another advantage of the code-on-chain tech is that, it would be very easy for DAC developers to upgrade the endpoint client program, delegates will debate which branch to upgrade, this will give the life to the DAC to grow and revolute to itself seamlessly even after it was lauched.

I think this would be one of the trends of future DAC development.

来自我的 GT-N7100 上的 Tapatalk

[alt]

I think we don't need to validating the code by delegate.
Just like create an asset don't need to validate.

market will validate the code.
some fee can pay to the address who publish the code.
after publish, he will introduce in the forum or whereever.
others can decide to play or not.
finally, market will give the player  good choice

[HackFisher]

Another question is that, if the logic of the blockchain script code has already be validated, then is there necessary to validate the output of the logic again in client?

[HackFisher]

For lotto, we should have multi and extensible rules, which could be easily deployed just as BTS assets and appstore. But for rules, they have definitions to describe them, the definition could be in the form of code. So how to keep the network reach a uniform consensus in each client node, without requiring to handle client program upgrading things.

The most effective way I'm thinking is to deploy/issue new rule and its logic code together inside the blockchain data, so client just need to sync the chain, pull the code from the chain, and run it in the local client (which could be a VM).

The way of validating this code could be indirectly through the delegates, if it is not so easy to validate by the clients.