Changes:

Improved UI:
It shows progress and how many blocks to get result for each dice in progress.

Improved security against delegates collusion:
The more amount you dice, the more blocks you have to wait for the jackpot. The block count calculation is roughly like below:
jackpot blocks = min(MAX_WAIT_BLOCKS,payout / delegate income)
MAX_WAIT_BLOCKS is currently set to 50.
Say, if you dice 100JDS with payout 20, and the delegate's income of the current block is 200, you'll need to wait for 10 blocks for the result.   
All the dices in the same block are sorted by payout and accumulated for the calculation of packout blocks.
Say we have 3 dices:[50@10, 100@2, 500@2].
We get payouts [500, 200, 1000] and they're sorted as [200,500,1000].
For 100@2, the accumulated amount is 200 and jackpot is 2 blocks.
For 50@10, the accumulated amount is 200+500=700 and jackpot is 4 blocks.
For 500@2, the accumulated amount is 200+500+1000=1700 and jackpot is 9 blocks.

The plan is to shuffle delegates after each block to improve security.

Original dry run info.:
https://bitsharestalk.org/index.php?topic=9393.0

Before I find a better way, I'll simply adjust the blocks to wait as below:

The more you bet, the more you wait.

If you're betting small, you get the result after 2 blocks. If you're betting bigger, you may need to wait for 3,4,...,50 blocks for the result.

I really like this adjustment.... the primary challenge is deciding who goes next in the event of a missed block.  You would have to "shuffle all remaining delegates".  Then what happens when the "short list" of delegates are all inactive. 

Start out with 100 delegates...
Shuffle the top 100
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 99
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 98
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 97
...
Shuffle the top 1
Produce a block, the delegate that produced the block goes to the end.
Shuffle the top 100

This would prevent a delegate from controlling everything while still keeping things random.

However you still have the probability that 2 delegates can collude to "always win". 

If "by chance" they see their two delegates back to back they can place a winning transaction. 

Your security is always going to be proportional to the number of individuals required to collude and what your tolerance is for that.

Hmm. You're right about the tolernce of number of individuals required to collude. As long as random is decided including the last delegate's secret, the delegate can know in advance the next delegate and if it's in  its control, they have the chance to collude.

Well, it's not acceptable for delegates to collude and it's also not acceptable for more than 2 blocks as fast feedback is key for this DAC. I'll look for other solutions like the one suggested by FreeTrade.

If you randomly select a new delegate each round then a delegate can take over all block production if the get two back to back slots by mining their secret.

Yes, you're right. Delegate can generate bunch of secrets and pick one which is appropriate to make him next one. Then we may still need more than 1 delegate in 1 round but the next delegate will still be decided based on this block's random. Let's say 50 delegates in 1 round and each delegate can produce only 1 block in 1 round. We can achieve this by excluding delegates who have already produced blocks in this round in next delegate choosing.

I prefer something like crosschain bitUSD but don't know whether it's easy to do. I want to make jds simple and will try to remove market related parts at least from UI.

You're Odds look wrong...

The probability of being greater than 49.5 is more than 50%... so I could be greater and win on average based on your screen shot.

I would recommend deriving chance to win and threshold from payout...

BET:   $10
Payout:   $100

Chance to win 1/100 * .99  (ie: dice < .0099)

I would also restrict the currency for betting to BitUSD on your network.... this will drive demand for BitUSD

It's a bug in UI display and it should be >50.5 or <49.5.

that one came from nowhere .. awesome!!

This Chinese thread explains the idea more in details and progress. I hope google translate understands it.
https://bitsharestalk.org/index.php?topic=8973.0

The DAC heavily used code from HackFisher https://github.com/bitsuperlab/bitshares_play/tree/dice. Thanks HackFisher. As the goal of this DAC is simple and quick, it's not integrated into Play for the moment.

To better avoid delegates cheating, I plan to randomly select next delegate from top 101. This means only 1 delegate in one round. But that is not a priority and can be implemented later.