昨天晚上翻看Bitshares Dice，没有看到相关的进度。可能他们都忙于BTSX了。不过可能思路不太一样。

我的想法是这样：
1.分配方案类似DNS。
2.名字就叫Just Dice Shares (JDS)。从名字可以看出会尽量借鉴JD，另外会保持尽量简单。
3. House Edge - 1%
4.所有JDS持有者为House。bet赢了的话，赢的JDS靠增发提供，这相当于所有JDS持有人按比例输给dicer。bet输了的话，输掉的JDS直接burn掉。这个与JustDice不一样，目的是简化方案而不影响效果。
5.投掷骰子后结果要尽量快出来。目标10秒内，争取5秒。
6.数学上保证公平，这个会限制5的速度。
基本想法是101个delegates,第n个delegate由第n-2个block的secret产生的随机数从top 101个中选一个。之所以选择n-2是为了保证可以提前1个块知道下一个delegate是谁，保证未来可能的网络优化。从101个delegates随机选是为了保证delegates没法作弊。

大致计划的想法:
我的时间特别有限，只能利用点半夜的时间，所以这里只是提出参考，再加上我的C也放下很久了，只能看懂代码，要写和调试比较困难，所以进度只能参考。希望能有高手加入或者直接按这个思路实现。
我比较习惯快速迭代或者说快速失败，所以计划是尽早发布（比如第一周就出testnet)。

1 week : clone BTSX的代码，改名为JDS，设置并运行testnet(JDST)。所以这一步只是BTSX的简单拷贝改名。
2 week: 投掷骰子，返回输赢结果并调整总体和dicer余额的cli支持
1 week: 投掷骰子的GUI支持
2 week: GUI重写，简化及优化。简化是去掉市场功能。优化是界面修改，比如使用大字体及移动风格。
2 week：完整GUI，比如my bets, all bets等等。

欢迎吐槽,建议或组队。

It's another mark of success. 

I think it will be cloned in 1 month.

I found my latest transaction was displayed as 501 while it should be something much larger.
It's same for GUI and console "wallet_account_transaction_history".
When I dig deeper into the transaction details, I found that the transaction has 2 withdraw operations. The reported amount 501 is of the last withdraw operation. Now I want to know what amount the receiver will see. I guess it should be fine as there's always 1 deposit operation in the transaction.
For those who have the same issue, I think it's only an issue from sender side and receiver will still see the correct amount.
But it's really annoying to see the incorrect amount in the first glance.
Can someone have a check and fix it in 0.4.5? Thanks.

要做BTS矿池应该比较容易，就是叫参与者投票到我的矿池就可以。
那么参与者为什么要投票呢？借用矿池的概念就好了，每个给我投票的人可以分红。比如挖矿的收入50%分红，每周分红。这样的矿池可以做到分布非常广，哪怕你只有一个BTS也可以参与挖矿。当然，如果发送分红手续费太高，可以设置进入的门槛，比如10BTS以上。

As the GUI is delayed, I'm interested in a GUI made in pure js.
The benefit:
1. quick
The html+css+js makes it very easy and quick to write GUI. I think I can make a very simple prototype in a week if I can have some spare time as long as JSON-RPC interface is ready.
2. cross platform
Even on mobile platform like ios and android.
3. responsive page design
This makes it look and feel well on different devices.
4. easy
JS is easier than C in my opinion.

If we need some kind of POW for randomness, why not directly use bitcoin blockchain as source of RNG? The random number can be something like the future nth block's hash. As bitcoin mining involves randomness, it's more secure for a random number generation. The block's hash is difficult to find and it will be difficult for a miner to adjust the hash to his will (to win a lottery) even if he has say 51% power. If we carefully choose the way to use the hash(like hashing it to get the result number), it can be very difficult (if not impossible) to control the result of lottery.

Maybe we can even chain the blocks by using the hash as another block's index to make it more difficult but I'm not sure whether this will break the randomness.

The down side is that every node (or at least some nodes) needs to download 2 chains to verify the block. But considering the mining power on bitcoin, I think it's worth to directly use bitcoin chain. To improve this, some nodes may choose bypassing download of bitcoin blockchain by not verifying the random number generation or directly getting hash value from some online services like blockchain.info.

Please correct me as I'm not a native speaker and could have some wrong understandings.
Suppose I'm a bad miner, what can I do? I can
1. Exclude some transactions. This doesn't harm much as I can only make few attacks in a short period of time. In fact, you can't even tell whether I'm a bad miner excluding some transactions or I'm a good miner who hasn't received the transactions yet.
2. Roll back some transactions by rolling back some blocks. This is interesting. But how can I do that?
Well, I need some percentage of shares. Let's say I have 10% shares. As the yearly inactivity fees exist, most of shares will have (maybe much) less than 365 coin days. I can easily accumulate my coin days to 50% by not destorying the coin days for 5.x years. Using the coin days I accumulated, I can roll back a large number of blocks. The number can be really large (like 100) as I have 50% of coin days. How many confirmations do you need to feel safe for a transaction? 6, 10? I would say at least 100. Considering I can choose time when large CDD happened one day before and the diversity of the shares, the percentage of shares I need will be much less.