46
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
中文 (Chinese) / 最新0.2.2版本Windows Crash反馈收集
« on: July 24, 2014, 05:45:17 am »
0.2.2版本应该修掉了一些Windows Crash的问题，但是有用户反映仍有问题，比如
https://github.com/BitShares/qt_wallet/issues/15
想对Windows下面的Crash问题做个统计，之前有问题的那些环境试一下0.2.2是不是OK了? 如果仍有问题，是什么错误，谢谢
https://github.com/BitShares/qt_wallet/issues/15
想对Windows下面的Crash问题做个统计，之前有问题的那些环境试一下0.2.2是不是OK了? 如果仍有问题，是什么错误，谢谢
48
DAC PLAY / Bitshares Lotto rule deployment, script code being part of blockchain?
« on: June 17, 2014, 03:13:44 am »
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.
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.
50
DAC PLAY / Nothing but a Play DAC Business Graph
« on: May 14, 2014, 04:09:57 pm »
Some note: End users might not to aware of lto share, just the rules and their chips. The disadvantage is that their might be too many chips, which could cause backward of usability?
51
中文 (Chinese) / Lotto支持多玩法并存的几种经济模型讨论
« on: May 13, 2014, 03:30:40 am »
概况：
Lotto是由核心层和玩法层组成，核心层包括块链交易手续费等DAC基础功能，有一个基本的货币或者叫股份单位(asset_type == 0)，暂且称之为lto。玩法层基于核心层构建各种各样的玩法，比如骰子，打赌, 乐透等等。 如果只有一种玩法的话，比较简单，就直接将lto作为该玩法的筹码就行了，这种情况下 筹码(chips)就和股份是一回事。
但是如果想支持多玩法，就会有一些复杂的考量，主要包含安全性(security)，流动性(liquity)，盈利性(inflation, profitable)，简单易用性(usability)几个方面。
下面列举几种选择，只是经济模型上的讨论，不涉及技术实现，供大家参考建议。
选择1：
只有一种主货币lto, 每种玩法都只有自己的筹码但没有自己的货币，若玩家想玩某个规则，就用lto买相应玩法的筹码参与游戏(筹码价格由各玩法自己定义)。lto的作用除了作为Lotto系统的通用货币外，支付交易费也必须使用lto。
这种情况下，各个玩法的筹码数量都是不固定和不稳定的，并且如果某种玩法的规则出现漏洞(比如庄家优势变成负，或者其他大奖漏洞)，那么这个玩法不仅会污染其他玩法，还且会对lto造成冲击，某些情况下有点像劣币驱逐良币，因为这种模型内部(不考虑lto与外部货币的交换)，只有一个中心的货币lto. 所以如果选择这种模型，每个规则必需非常谨慎对待，需要被开发人员Review，然后经过投票等等审核。 但这个模型是跟现实中比较接近的一种。
选择2：
也许也有一个主货币lto, 但是每个玩法都有自己独立的货币， lto的作用主要是作为其他玩法的拍照(Genesis allocation) 以及交易费用。 这样的情况下多个规则会造成多个数字资产，货币(或股份share)单位会很多，好处是他们之间可以相互竞争，优胜劣汰，不会有劣币驱逐良币的问题，缺点我认为是造成了货币单位数量的膨胀，感觉内部流动性和易用性都会出现问题，如果靠外部交易所来保持流动性也不简单，需要有很多工作要做，一旦拍照对lto本身主货币和品牌也没有贡献。
选择3：
有点类似于最近讨论的比较火的side chain的方案，双向挂钩(pegging)。 仍然有一个主货币lto， 每个玩法也有自己的货币(或者叫筹码)。 但是不同之处在于，每个规则在发行货币时，是需要一定数量的主货币做担保背书和冻结的。
举个例子，比如dice rule打算发行(注1) 100,000的dice chips， 以1000 lto作为担保背书冻结(1lto = 100 dice chips)。 那么在dice chips内部，随便怎么玩，都用dice chips作为计价单位，赌注和奖金单位，通胀和通缩都可以。 但是同时，系统也支持chips和lto的兑换，这个兑换的精髓就是双向挂钩。以dice chips当前的总量供应(total supply) 和该规则的所有担保数量(1000 lto)之比作为兑换价格。 请注意，这个兑换是双向的，可以增资(lto-> dice chips)也可以撤资(dice chips -> lto)。 我现在比较喜欢这个模型，不知道有没有什么其他问题，欢迎讨论。
注1：可以个人发行，也可以系统发行，系统发行的方式可以选择系统按照lto等比例拍照(Snapshot)产生chips.
Lotto是由核心层和玩法层组成，核心层包括块链交易手续费等DAC基础功能，有一个基本的货币或者叫股份单位(asset_type == 0)，暂且称之为lto。玩法层基于核心层构建各种各样的玩法，比如骰子，打赌, 乐透等等。 如果只有一种玩法的话，比较简单，就直接将lto作为该玩法的筹码就行了，这种情况下 筹码(chips)就和股份是一回事。
但是如果想支持多玩法，就会有一些复杂的考量，主要包含安全性(security)，流动性(liquity)，盈利性(inflation, profitable)，简单易用性(usability)几个方面。
下面列举几种选择，只是经济模型上的讨论，不涉及技术实现，供大家参考建议。
选择1：
只有一种主货币lto, 每种玩法都只有自己的筹码但没有自己的货币，若玩家想玩某个规则，就用lto买相应玩法的筹码参与游戏(筹码价格由各玩法自己定义)。lto的作用除了作为Lotto系统的通用货币外，支付交易费也必须使用lto。
这种情况下，各个玩法的筹码数量都是不固定和不稳定的，并且如果某种玩法的规则出现漏洞(比如庄家优势变成负，或者其他大奖漏洞)，那么这个玩法不仅会污染其他玩法，还且会对lto造成冲击，某些情况下有点像劣币驱逐良币，因为这种模型内部(不考虑lto与外部货币的交换)，只有一个中心的货币lto. 所以如果选择这种模型，每个规则必需非常谨慎对待，需要被开发人员Review，然后经过投票等等审核。 但这个模型是跟现实中比较接近的一种。
选择2：
也许也有一个主货币lto, 但是每个玩法都有自己独立的货币， lto的作用主要是作为其他玩法的拍照(Genesis allocation) 以及交易费用。 这样的情况下多个规则会造成多个数字资产，货币(或股份share)单位会很多，好处是他们之间可以相互竞争，优胜劣汰，不会有劣币驱逐良币的问题，缺点我认为是造成了货币单位数量的膨胀，感觉内部流动性和易用性都会出现问题，如果靠外部交易所来保持流动性也不简单，需要有很多工作要做，一旦拍照对lto本身主货币和品牌也没有贡献。
选择3：
有点类似于最近讨论的比较火的side chain的方案，双向挂钩(pegging)。 仍然有一个主货币lto， 每个玩法也有自己的货币(或者叫筹码)。 但是不同之处在于，每个规则在发行货币时，是需要一定数量的主货币做担保背书和冻结的。
举个例子，比如dice rule打算发行(注1) 100,000的dice chips， 以1000 lto作为担保背书冻结(1lto = 100 dice chips)。 那么在dice chips内部，随便怎么玩，都用dice chips作为计价单位，赌注和奖金单位，通胀和通缩都可以。 但是同时，系统也支持chips和lto的兑换，这个兑换的精髓就是双向挂钩。以dice chips当前的总量供应(total supply) 和该规则的所有担保数量(1000 lto)之比作为兑换价格。 请注意，这个兑换是双向的，可以增资(lto-> dice chips)也可以撤资(dice chips -> lto)。 我现在比较喜欢这个模型，不知道有没有什么其他问题，欢迎讨论。
注1：可以个人发行，也可以系统发行，系统发行的方式可以选择系统按照lto等比例拍照(Snapshot)产生chips.
52
中文 (Chinese) / 一注彩票的“注”在英文中怎么翻译？
« on: May 11, 2014, 03:07:40 pm »
英文该怎么说，有人知道么？
RT
还有“筹码”英语怎么说？bargaining chip? 感觉太长了
RT
还有“筹码”英语怎么说？bargaining chip? 感觉太长了
53
DAC PLAY / updown.bit future event gaming
« on: May 09, 2014, 02:40:56 pm »
https://updown.bt/
Would like to have a simple UI like this, may need some help from designers...
Although I think this site is not easy to use, it spent me a lot time to pass through the step by step guide.
Do anyone knows where its public seed come from?
Would like to have a simple UI like this, may need some help from designers...
Although I think this site is not easy to use, it spent me a lot time to pass through the step by step guide.
Do anyone knows where its public seed come from?
54
DAC PLAY / Ticket-based betting rule (To be updated)
« on: May 05, 2014, 04:16:36 pm »
1. one random variable using block generated random number, R1
2. another random variable using ticket transaction hash rather than ticket generated lucky number. R2
3. ticket win condition:
Range = 100000000
(R1 % Range + R2 % Range ) % Range < Range/odds.
4. Payout accounting using chancecoin's approach
http://chancecoin.com/technical
5. share dividends each block == house edge. (expect result in long term)
6 no need to care/log ticket sale, expected winners, etc...., each ticket is independent from others.
more to draft, this feature is now quite similar to the classic satoshi dice.
2. another random variable using ticket transaction hash rather than ticket generated lucky number. R2
3. ticket win condition:
Range = 100000000
(R1 % Range + R2 % Range ) % Range < Range/odds.
4. Payout accounting using chancecoin's approach
http://chancecoin.com/technical
5. share dividends each block == house edge. (expect result in long term)
6 no need to care/log ticket sale, expected winners, etc...., each ticket is independent from others.
more to draft, this feature is now quite similar to the classic satoshi dice.
55
DAC PLAY / X Winners Block-based Betting Rule
« on: May 05, 2014, 09:29:19 am »
TICKET_SALE: total tickets sales in this block.
TICKET_AMOUNT: amount of ticket output, users must pay that for the ticket
TICKET_ODD: the odd of the ticket, user can specify this to influence the chance of winning and correspond payouts. 2 means 50% chance of winning and 2x payout.
TICKET_LUCKY_NUMBER: User specified lucky number, betting the winning result.
RANDOM_NUMBER: random number for this block.
X: Maximum of winners block are going to payout jackpots, Expect_Winners
E: house edge, e.g. 1%, will go to prize pool for risk handle….
------
Chance of winning for the ticket = (Ticket_Amount * X) / (TICKET_SALE * TICKET_ODD)
Total_Jackpot for the winning ticket = ((1 - E) * Ticket_Odd * TICKET_SALE) / X
Winning condition for the ticket:
HASH(RANDOM_NUMBER+TICKET_LUCKY_NUMBER) % (TICKET_SALE/TICKET_AMOUNT) < ( X / TICKET_ODD)
OR
HASH(RANDOM_NUMBER+TICKET_LUCKY_NUMBER) % {TICKET_ODD * TICKET_SALE/ (TICKET_AMOUNT * X)} < 1
-----
Risk analysis:
Risk means there is no enough funds to payout.
There is possibility that the ticket sale is not enough for payout jackpots, this case must be handled by using pool, or dynamically adjust the payout jackpots. Pool seems to be better but with more challenge.
The range of TICKET_LUCKY_NUMBER will influence the risk, the smaller the risk will be larger for the case of too many winner will happen, so the winner number threshold should be large.
that is, {TICKET_ODD * TICKET_SALE/ (TICKET_AMOUNT*X)} should be close to the Range of TICKET_LUCKY_NUMBER.
Large TICKET_ODD could increase risk, because the chance to paying extreme large will increase. so there should be a range to limit.
Product analysis:
I think the disadvantage is that, it is not user-friendly, user is hard to understand what lucky number is (actually similar to betting dice? Then how about just letting user to a dice number from 1 - 6 for the user interface? in this case, we need X to be large to reduce the risk), and how will it affect the winning condition. So, no fun and meaningless for user to specify that.
Advantage is easy to implement.
Refer:
https://bitsharestalk.org/index.php?topic=4164.msg52868#msg52868
TICKET_AMOUNT: amount of ticket output, users must pay that for the ticket
TICKET_ODD: the odd of the ticket, user can specify this to influence the chance of winning and correspond payouts. 2 means 50% chance of winning and 2x payout.
TICKET_LUCKY_NUMBER: User specified lucky number, betting the winning result.
RANDOM_NUMBER: random number for this block.
X: Maximum of winners block are going to payout jackpots, Expect_Winners
E: house edge, e.g. 1%, will go to prize pool for risk handle….
------
Chance of winning for the ticket = (Ticket_Amount * X) / (TICKET_SALE * TICKET_ODD)
Total_Jackpot for the winning ticket = ((1 - E) * Ticket_Odd * TICKET_SALE) / X
Winning condition for the ticket:
HASH(RANDOM_NUMBER+TICKET_LUCKY_NUMBER) % (TICKET_SALE/TICKET_AMOUNT) < ( X / TICKET_ODD)
OR
HASH(RANDOM_NUMBER+TICKET_LUCKY_NUMBER) % {TICKET_ODD * TICKET_SALE/ (TICKET_AMOUNT * X)} < 1
-----
Risk analysis:
Risk means there is no enough funds to payout.
There is possibility that the ticket sale is not enough for payout jackpots, this case must be handled by using pool, or dynamically adjust the payout jackpots. Pool seems to be better but with more challenge.
The range of TICKET_LUCKY_NUMBER will influence the risk, the smaller the risk will be larger for the case of too many winner will happen, so the winner number threshold should be large.
that is, {TICKET_ODD * TICKET_SALE/ (TICKET_AMOUNT*X)} should be close to the Range of TICKET_LUCKY_NUMBER.
Large TICKET_ODD could increase risk, because the chance to paying extreme large will increase. so there should be a range to limit.
Product analysis:
I think the disadvantage is that, it is not user-friendly, user is hard to understand what lucky number is (actually similar to betting dice? Then how about just letting user to a dice number from 1 - 6 for the user interface? in this case, we need X to be large to reduce the risk), and how will it affect the winning condition. So, no fun and meaningless for user to specify that.
Advantage is easy to implement.
Refer:
https://bitsharestalk.org/index.php?topic=4164.msg52868#msg52868
56
DAC PLAY / Play Detail Technical Design Discussions
« 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.
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.
57
DAC PLAY / Play Ticket
« on: April 29, 2014, 08:14:50 am »
Play Ticket is to support float amount prize, be in your balance as a kind of asset. Not spendable and transferable.
There is challenge for rule layer designer, about how will the amount influence your jackpot drawing, but that is up to rule layer, I think may be odds is also involved together with amount to affect the result of jackpots.
Ticket has owner, so people could buy ticket for other people as the owner of the ticket, which could be useful in the charity donation, donate in tickets?
There is challenge for rule layer designer, about how will the amount influence your jackpot drawing, but that is up to rule layer, I think may be odds is also involved together with amount to affect the result of jackpots.
Ticket has owner, so people could buy ticket for other people as the owner of the ticket, which could be useful in the charity donation, donate in tickets?
58
Stakeholder Proposals / Bit Super Lab
« on: April 11, 2014, 03:49:31 pm »
After reading the DPOS whiter paper, I have an idea to form a super lab to join the competition of DPOS mining, because providing good service as a stable DPOS delegate is a challeging work, and could be very interesting and profitable.
Two goals:
1. Act as one of the 100 delegate mining nodes, and keep stable with high reputation, 100% online.
2. Testing DPOS network, reseach on all kinds of attack and cheating possibility. Find the flaw of other 99 mining nodes.
Any ideas, or anybody intent to collaborate?
来自我的 GT-N7100 上的 Tapatalk
Two goals:
1. Act as one of the 100 delegate mining nodes, and keep stable with high reputation, 100% online.
2. Testing DPOS network, reseach on all kinds of attack and cheating possibility. Find the flaw of other 99 mining nodes.
Any ideas, or anybody intent to collaborate?
来自我的 GT-N7100 上的 Tapatalk
59
DAC PLAY / Rebranding
« on: April 04, 2014, 03:13:02 am »
LOTTO is rebranded and is part of Charity now. The broad name are changed with the help of Amazon.
https://bitsharestalk.org/index.php?topic=3983.0
let you know instead of confusing.
Besides, Lotto is still be part of Gaming too, I think it is more like a common shared service DAC now.
https://bitsharestalk.org/index.php?topic=3983.0
let you know instead of confusing.
Besides, Lotto is still be part of Gaming too, I think it is more like a common shared service DAC now.
60
DAC PLAY / Bitshares Play two layers design
« on: March 31, 2014, 07:24:16 am »
Here some ideas to share with you. If you are going to create new DAC based on Bitshares Play, this info might be helpful to you to save your time.
I would like to design play in two abstract layers, the rule layer and the core layer, which will make it very easy to create a alt-play, for play family dac creator.
First, The rule layer is all about the game rule of the play, x of y, or serveral independ color balls with different total and k to select, similar the options in https://bitsharestalk.org/index.php?topic=3818.0
And the play family Dac creators can select whatever kind of rule they like, color counts, ball count, k to select, prize definition. The outer rule layer will also provide simple api for inheritors to customize prizes rules.
Meta data of this rule layer can be described as following json data, inherit DACs could customize it to create alt-play.
{
version: 1,
id: 1
name: "double-color ball lottory",
rule: {
balls: [
{N: 35, k: 5},
{N: 12, k: 2}
],
prizes: [
{level: 1, match: [[5, 2]]},
{level: 2, match: [[5, 1]]},
{level: 3, match: [[5, 0]]},
{level: 4, match: [[4, 2]]},
{level: 5, match: [[4, 1]]},
{level: 6, match: [[4, 0], [3, 2]]},
{level: 7, match: [[3, 1], [2, 2]]},
{leve;: 8, match: [[3, 0], [1, 2], [2, 1], [0, 2]]}
]
}
}
Second, the core layer is nothing but a true random number decentralized raffle process protected by mining, blockchain db etc.
I would like to design play in two abstract layers, the rule layer and the core layer, which will make it very easy to create a alt-play, for play family dac creator.
First, The rule layer is all about the game rule of the play, x of y, or serveral independ color balls with different total and k to select, similar the options in https://bitsharestalk.org/index.php?topic=3818.0
And the play family Dac creators can select whatever kind of rule they like, color counts, ball count, k to select, prize definition. The outer rule layer will also provide simple api for inheritors to customize prizes rules.
Meta data of this rule layer can be described as following json data, inherit DACs could customize it to create alt-play.
{
version: 1,
id: 1
name: "double-color ball lottory",
rule: {
balls: [
{N: 35, k: 5},
{N: 12, k: 2}
],
prizes: [
{level: 1, match: [[5, 2]]},
{level: 2, match: [[5, 1]]},
{level: 3, match: [[5, 0]]},
{level: 4, match: [[4, 2]]},
{level: 5, match: [[4, 1]]},
{level: 6, match: [[4, 0], [3, 2]]},
{level: 7, match: [[3, 1], [2, 2]]},
{leve;: 8, match: [[3, 0], [1, 2], [2, 1], [0, 2]]}
]
}
}
Second, the core layer is nothing but a true random number decentralized raffle process protected by mining, blockchain db etc.
