BitShares Forum
Other => Graveyard => DAC PLAY => Topic started by: HackFisher on April 29, 2014, 01:14:44 pm
-
During the development of Lotto, I found that I have to make some design decisions which is better to be peer reviewed, and I like the process of debate different decisions to clarify things out.
So I'll draft the ideas relate to lotto design here, which could be new approach, or design decisions I'm not sure.
More details about Lotto could refer https://github.com/HackFisher/bitshares_toolkit/issues?state=open
Let's begin with following three.
1. Currently jackpots draw transactions are created by ticket owner, could they be deterministic transactions which is not broadcast by network but updated on each node itself? Deterministic transactions could be generated and update to blockchain once winning number is out.
2. Going to support different jackpots draw output, claim_signature or claim_jackpot (support not spendable util time, like COINBASE_MATURITY), but should the maximum assets in each jackpot be limited in core layer or rely on the designer of rule layer.
3. Secrets to generate random number are claimed in the first transaction of each block like bitcoin coinbase trx, not block header which I think is not for extend.
Please quote those questions which are not clearly posted.
-
4. Different assets for different rule layers.
-
5. Ticket will be show in balance, and ticket has its owner, when someone buy a ticket, he can customize the ticket owner address which is no required to be himself. So there will be use case like Alice buy a ticket for Bob, the ticket will show in Bob's balance rather than Alice.
-
1) There is no need for either. The ticket output is spendable as the jackpot if that ticket is the winning ticket.
2) There should be a core layer which only lets you request payouts in terms of fraction of the pool (but possibly multiple pools). The rule layer should handle how each pool is distributed to winners. Enforce cash-flow positive then let the rest be whatever.
3) I think secret store/reveal can just be normal transactions right? Don't think of it as special delegate/block producer role
4) ??
5) Good
-
4) ??
Different assets for different rule layers.
The general idea is that if we design lotto as a rule platform, for different rules to compete with each other, I think it might be better for each rule to have its own asset, then the market could reflect the competition result.
The opposite approach is why 2) is posted, if different rule share one asset, it could be a problem if there is no jackpot draw limitation.
-
1. Currently jackpots draw transactions are created by ticket owner, could they be deterministic transactions which is not broadcast by network but updated on each node itself? Deterministic transactions could be generated and update to blockchain once winning number is out.
A more general question, should ticket draw transaction be signed by ticket owner, delegate, or automatically(as deterministic transactions) ?
PS: The ticket owner must be the jackpots owner(or who is defined to be the Beneficiary in the ticket, might be useful in the use case of charity), there is no need to change that after the winning number is out.
-
6. If one of tx.inputs are claim ticket, then all its inputs should be claim tickets, and all output should be claim jackpot. And all the mature_day of the outputs must allocate in different days.
This is to avoid customized trx that break the maximum draw amount per ticket per day, by involving other outputs like claim signature.
-
2. Going to support different jackpots draw output, claim_signature or claim_jackpot (support not spendable util time, like COINBASE_MATURITY), but should the maximum assets in each jackpot be limited in core layer or rely on the designer of rule layer.
To simple the design, ticket can should only be draw by claim_jackpot, and maximum each jackpot output per day is limited in rule layer.
3. Secrets to generate random number are claimed in the first transaction of each block like bitcoin coinbase trx, not block header which I think is not for extend.
Claim secret transactions are now just normal transaction created by delegate, but with the limitations that there should be and only be one secret output in each block(except genesis).
And combined 6) and 1), and fees consideration, ticket->jackpot transactions are now deterministic transactions without fees and votes. But there is still some detail issue need to fix, because current implement of toolkit requires each trx have fee and votes, including deterministic trxs.
https://github.com/BitShares/bitshares_toolkit/issues/48 (https://github.com/BitShares/bitshares_toolkit/issues/48)