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).
I really like this approach and am attempting to internalize it.
Glad you like it
However I just realized I was a little too hasty in assuming the probability to broadcast a block was proportional to the coins you owned.
This is because when you are a small owner, you do not just need to be lucky to publish a block, you also need
all the bigger owners to be (much) less lucky than you.
In other terms, it's not BCD that should be proportional to the number of coins owned, it's the probability that your score will be the highest, which is not the same.
A quick fix would be to use "lottery tickets" instead of addresses. Each ticket has a value equal to hash(signature(hash(previous_block)+sequence_number)). If you have 3 coins, you have 3 tickets (sequence numbers 1, 2 and 3. All tickets are equivalent, so this time your odds to win are truly proportional to your number of coins, i.e.: number of tickets.
Then when time_since_last_block^n * AND(ticket, hash(previous_block)) == target, you can claim your gains by broadcasting the new block, with your signed message embedded.
If you try to claim ticket 4, it won't work because the other nodes know you don't have 4 coins.
The use of a signature is to deter people from trying to guess other people's tickets and engineering blocks that would be better for them (adding/shuffling transactions). It might not be necessary, depending on how long/how much it takes.
EDIT: another variant, even closer to PoW. Remove time_since_last_block from the target calculation. Instead, everybody draws additional tickets every second: ticket = hash(signature(hash(previous_block)+sequence_number+seconds_since_last_block)). Now it truely is like PoW, and there is some hashing involved, but your contribution is capped by your stake and not by your hardware. If you have 1000 coins, your are capped at 1kH/s. Of course, units are arbitrary.
The benefit is that it makes block generation time less variable.
EDIT2: It seemed to me all these lottery systems are potentially vulnerable to block engineering: if someone had enough hashing power, they might be able to produce favorable blocks with very few coins, by performing minor changes on the list of transactions.
I suppose the system could be made resistant to block engineering by only taking the hash of fields in the block that cannot be altered for lottery purposes, like the signature of the reward claimer and the block height. If you have a ticket good enough to claim the reward, your only degree of freedom is to claim it or not, so your possibilities for block engineering are very limited.
New blocks still have to reference the hash of the previous full block (i.e.: including transactions) though, for obvious security/consensus reasons.
Topic: Transactions as Proof-of-Stake & The End of Mining (Read 63819 times)
