Initial prototype (http://114.215.104.153:8081/main.html), repository:(https://github.com/zhangweis/bts-ui/):

• Tested only on chrome but could possibly work on ios and android.
• Angularjs based.
• Responsive design (layout from coinpunk)
• Page switch between transactions and send.
• Really not good at page design and need some help.

To do:
node+webkit packaging (should not be hard, but automation could be)
make data layer and simulate JSON/RPC

We can even setup a blockchain-like online wallet service using coinpunk code. But I don't know whether running a service like this is legal or not (considering lotto.).

If an attacker can gain control of the last N delegates before the drawing then they would be able to improve their odds by 2^N. 

To solve all of these problems a given round is either all or nothing.  Either all 100 delegates report in or no random number is generated.

Well, I have an easier and a more secure idea to solve this. The problem here is that there's no randomness in choosing next miner. This can be easily solved by using generated number [HASH(S1,...S100)] to decide next miner. Say the miner index is M. If the designated miner doesn't produce block in time, miner (M+1)%100 will be designated. Maybe we can use previous 99 S to generate another number to improve the randomness.

It's relatively easier to abandon a number that i don't want(by not producing a block) but difficult or even impossible to generate a number i want. All a cheater can do is just another dice. Thus next miner to generate block(M) is difficult/impossible to control. This ensures every one of 100 has the equal chance to produce a block.

I strongly suggest to apply this to dpos itself. Let's take exchange for example. If I controll M, M+1, M+2, I can manipulate the market(price) for several minutes by excluding some transactions. If next miner M is decided by RGN, the worst I can do is to exclude some transactions for less than a minute and I don't even know when I can do this. This reduces the risk of delegates' controlling blocks very much.
From user point of view, next miner is known when this block is retrieved. Thus this doesn't sacrify efficiency and the wallet/network still knows who to send the transaction to.

The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

The votes come only from board of directors and they're motivated to vote. You can refer to https://bitsharestalk.org/index.php?topic=4176.0 for my idea. Basically the DAC can run just like http://bitbet.us/. It runs like below:
1. Any shareholder (maybe with at least 0.01% of share) can start a bet with some description.
2. Delegates vote whether the bet is clearly stated and can be judged when the event happens.
3. Delegates vote on the result when the vent happens. Multiple delegates can vote on the same bet and will split some portion of the bet's payout.
4. Shareholders can view their delegates' vote from wallet and can vote against them if they cheat.

I think board of delegates can be the source for some event's result as long as the revenue of staying as BOD is bigger than cheating.
The wallet will show recent event's result your delegate votes. In case of cheating, you can vote against the delegate. Some percentage of payout can be used as the incentive for the delegates to vote. Multiple delegates can vote on the same event and split the fee to encourage more delegates vote on the same event.
In this way, we can set up a DAC competing with http://bitbet.us/.
Just some rough ideas. Does this make sense?

你的方案引入太多政治，我觉得可能带来的更多是问题。

Successfully re-registered with (john) public key: 6cTkAWcJs881Dq7K4KwCFUWxVfNafNfsXr16Li2AEH7BbjY1YG