1
General Discussion / Re: RDPOS - Recommended Delegated Proof of Stake
« on: July 24, 2014, 12:41:03 am »
What happened to the idea of having automatic votes based on past performance as default?
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
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.
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.
CD can only apply to one chain at a time. So I think we are on the same page.Can they? I think this can be enforced, but by default it isn't, since coin age depends on the date of the last transaction, which depends on which chain you are on. After a fork, coins accumulate CDs on every chain, which is something PoW does not have to deal with.
I agree vesting would take influence from people transacting every block and give it to savers. An attacker would then have to hold his coins longer.I think I see where we differ finally
I think we have something.Not sure what you're thinking about, but I'll await it eagerly
Lets assume that there is no delay in CD accumulation then an attacker with 1/50,000 of the money supply could spend enough CDD every other block to build 50% of the blocks on average. Putting a delay before CD start accumulating of 100 blocks means the attacker would only have 1% influence on block production assuming 1/50,000 of the money supply.
Assuming you want to take on the role of securing the network, rather than just 'using the network' which is what 99% of users will be doing. They may randomly profit when they happen to have the most coindays destroyed (because it is their first trx in a year). So lets assume there is a certain base level of CDD providing security regardless of any other financial incentive.No, this is just what an optimized client would do. Sooner or later it will be available to the public.