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.
Topic: Transactions as Proof-of-Stake & The End of Mining (Read 112019 times)
