I recently came up with another system that could work, though I am not fully sold on it.
What if the share holders elected people who would sign blocks? You vote for the signers with CDD. When they sign they spend the CDD they accumulated from people voting for them. No one would be allowed to sign more than 1 in 100 blocks.
This plan has many potential problems, but I thought I would add it to the idea pool.
Wouldn't that generate an awful lot of network spam? At each block, each node would have to know what each other node has voted?
I have an idea based on a lottery system.
It requires the introduction of another type of coin-days that are reset after each block. I'll refer to as BCDs, for Block Coin-Days.
After a node receives a block, it takes the hash of the block and the hash of its Bitshares address, and applies a binary AND on them. The result is a speed of BCD gain per coin.
The node can then compute the number of BCD held by its address as a function of time: BCD = time_since_last_block * (block_hash AND address_hash) * number_of_coins.
It will broadcast a block when the amount of BCD reaches a target set by the protocol, depending on previous blocks. The block must reference the outputs used to generate the BCDs.
The idea is that the node with the highest BCD gain speed ((block_hash AND address_hash) * number_of_coins) will win. As time passes, it is more and more likely that someone will meet the target (like PoW), and the randomness prevents the biggest stake-holders from always publishing the block. They still have more chance of meeting the target though, since the expected value of the BCD gain speed is proportional to the amount of resources owned (also similar to PoW).
Unlike some other lottery systems addresses, this does not reward splitting your funds into multiple addresses.
Difficulty target can be initialized analytically to target a specific block generation time, as the distribution of Protoshares can be calculated at the genesis of Bitshares. However, I think target adjustment would have to be completely empirical afterwards (increase if blocks are generated too fast, decrease if too slow).
To help constrain block generation time, I think a polynomial weighting of time could be used (e.g.: use time_since_last_block^4 instead). If time_since_last_block < 1, it is harder to reach the target. If time_since_last_block > 1, it is easier. Stronger degrees increase this effect.
Latency is not an issue, given that if you receive two blocks, you can easily see which one met the target first. However, this implies using the sum of BCDs to determine the main chain (at least to some extent).
