What happened to the idea of having automatic votes based on past performance as default?

Quote from: arkanaprotego on December 10, 2013, 04:22:21 pm

Quote from: bytemaster on December 08, 2013, 11:19:15 pm

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.

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).

Having to let CDs vest sounds reasonable, since that would also prevent people from spamming the network with transactions to themselves.

However I don't see the need to prevent CDs from being reused constantly, it is their purpose. I think there might be some confusion about the temporal aspect of CDs, as you seem to view coin-days only as a resource that accrues in the hands of stakeholders and that can be engineered at will.

The original idea behind coin-days is to measure how many coins back each side of the fork. A coin is detected as supporting a chain when a transaction involving this coin is added to that chain. However, if we simply summed transaction volumes, fast circulating coins would have a disproportionate weight compared to slower circulating ones, and this could trivially be exploited. So we create a new metric by weighting each transaction by (age of the coin at the moment of the transaction)/(time since reference, ex.: genesis), which ensures that all coins have a weight equal to their value, to vote by transactions on what happened between the reference time and now (because the sum of the ages of the coin at the moments of the transactions is equal to the time elapsed since the reference). Since the time since the reference is present in all weights, you can simplify the expressions by multiplying by it everywhere, and you are left with coin-days as vote weights. This is where coin-days come from.

Given expression of coin-days, the rate at which coins accrue coin-days is constant (1/coin/day), and attempts to alter it will break the proportionality between vote value and coin value if the last equality is not verified  (e.g.: with delay, the sum of weights depends on the number and spacing of transactions).
Also notice that it is tricky to use the timestamp of the fork as a reference time, since it won't exactly match transaction dates for most of the coins. As a consequence, right after the fork, branches start with non-zero and most likely non-equal supplies of CDs. In other words, one chain might have a substantial head-start.

My proposal to address this is to force the spending of CDs regularly, so that branches will always start with close to 0 CDs. This can be done by capping coin age to 1 day and by rewarding everybody for destructing their CDs. Under these conditions, the longest branch is automatically the one in which the alive nodes own the most wealth. It also prevents attackers from accumulating CDs in secret (or accumulating CDs at all).

If you really do not want to automate the destruction of CDs, another way to do would be to implicitly reset coin-days at the fork, by not counting CDs accrued before the fork.
Is it what you wanted to suggest? If you really meant not counting CDs accrued after the fork, your metric to evaluate forks would fail to confirm the right branch if the attacker has more CDs when they initiate the attack. And I think it is the only case when an attacker would bother to start a fork, or the fork could be annihilated instantly by the users of the main branch, provided they are programmed to destroy more CDs in case of a forking attempt.

If you go with the second solution (I think the first one does not really need it, but it might still be safer to do it regardeless), it would be nice to prevent CDs from the same outputs from being destroyed in several chains, as it would reduce the gap between the two chains.
The goal is to prevent honest nodes from irreversibly supporting the attack in good faith, if they mistake an attack for the rightful chain during the time it takes the main chain to reestablish its dominance.
A soft way would be to add a rule to the honest clients so they don't reuse outputs.

bytemaster,

Thank you for your clarifications, but I am not sure you can neglect time that easily when considering security.

1) The best usage of your CD is still to spend them when you are the most certain that you will be the biggest CD destroyer.

3) Let me try another, more graphic attack to show some issues and try to solve them.
I have 34% of the coins. I don't move them for a year, to get the maximum CD out of them. Then I transfer them all to myself. I am most likely the biggest destroyer of CD in the block. I don't sign it. Now 4 sub-cases:
a) You ban my output and start another block without it. Right after that, I broadcast my signed block. Now all the new nodes that are plugged into the network and were not there when you banned me will follow me, because I have the chain with the biggest CDD, and you cut yourself from it. They can also not trust your ban, since you look like the attacker.
b) You don't ban it and start another block without it. I wait for a year. During this year, the average coin is moved every 2 days. With the 1 day delay after each transaction, your 66% coins generated and destroyed less CD than my 34% had then. I publish the block I had saved, and instantly reverse 1 year of transactions. Note that the more you move your coins, the less I need coins.
c) You don't ban it and include it in your next block, signed by #2 CD destroyer. You are quite sure to be in the longest chain of CDD and I have lost all my CD, unless... I publish the block, which is what you wanted me to do in the first place. I must do it fast, because if I wait too much, you will add more transactions to your chain and your chain will be longer in CDD than I can make mine.
d) Same as c, but I lied and I actually had 40% of the coins. After you start on your version of the block with my 34%, I wait until you destroy nearly as much as my remaining 6% are worth in CD, and publish a block with my 6%. This might take long or not, depending on the volume of transactions.

Long story short, I think the delay on CD regeneration is dangerous, because it creates distortions that can be exploited both ways, and that counting security in CDD is quite impractical if CD are not destroyed linearly, as it exposes you to forks originating far in the past. If C coins have not moved since a date T, and CDD(T, now) coin-days have been destroyed between date t and now, then the chain can be forked back to its state at t by someone who controls the coins if:
CDD(t, now) < C*max(now-T, 1 year)
To prevent this, CDD must be high. However, due to the delay, it is faster to generate unspent CD than to destroy CD.
With no delay though, the fork that accumulates CDD at a faster rate is always the one that has the most coins backing it. If these CD were spent automatically, they would prevent forks, as well as the accumulation of CD required for a fork.

I think the vesting period is a brilliant idea to keep only interested investors.

However I cannot see why you would like to ruin hopes of profit for everybody by using a lottery system. Building on people's irrationality rather than rationality is a terrible choice in my opinion. This will unnecessarily decrease the attractiveness of Bitshares for rational people who are not already convinced, and I don't think many people like to think of themselves as irrational. As you have written yourself in the OP, miners who use only commodity hardware already have an edge over mass miners since they do not have an investment to recover, so I don't know why you go to such lengths.

I agree that Bitshares distribution should not reward the richest, but I think the problem can only correct itself. If there is profit to be made by cloud mining, then people will invest more into VPS, eventually lowering the profits until no one can get a ROI on hiring a VPS (provided the difficulty adjusts fast enough). But then there will still be profit to be made by single PC miners, who do not need any ROI, and they will be able to push VPS users out of the game, as the number of flesh and bones investors grows and the power shifts from mass miners to single PC miners.

If you want to restrict mining to home computers, consider involving a GPU in the proof of work. I had an idea like this: keep sealing the blocks with a CPU-only PoW, but also require some GPU-only work in the body of the block. If you are willing to surrender a little bit of decentralization, you could even make the GPU work something scientifically useful, like in Curecoin: you could make the reward of the block proportional to the points earned in a distributed computing project like Folding@Home (with a cap and an adaptive exchange rate). Such scientific programs also run on CPU but much slower, so this penalizes cloud instances. ASIC are out of the question for such evolving applications. This leaves botnets: I don't think it would be very easy for a botnet operator to make a GPU scream without drawing some attention, but this is only supposition. The issue is that the point tally depends on a central authority. This could be alleviated by including other research programs. This also poses the question of how points are checked: each node of the network will need to check the points to validate the reward and the block, which will cause massive traffic on the websites of the scientific projects, and will look like a DDoS.

About decentralization, I think a giant, built-in P2Pool system could be the way to go. I am not too sure how it scales though. Pool difficulty must be high enough to avoid network spam, which means it would still be kind of a lottery system, but with lower variance. As far as I am concerned, if I am sure to get a reward at least once every 1-3 months, it could be acceptable.