Author Topic: Play Detail Technical Design Discussions  (Read 3119 times)

0 Members and 1 Guest are viewing this topic.

Offline HackFisher

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

Quote
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
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 HackFisher

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

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

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
4) ??

Quote
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.
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 toast

  • Hero Member
  • *****
  • Posts: 4001
    • View Profile
  • BitShares: nikolai
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
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline HackFisher

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

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
4. Different assets for different rule layers.
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 HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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.
« Last Edit: August 12, 2014, 12:36:29 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.