In order to prevent this kind of behavior we must make it impractical for miners to maintain secret block chains. If every transaction that is broadcast contains the hash of a recent block and the block chain enforces the rule that the transaction’s proof-of-stake can only be credited in block chains that build off of that block then no one will be able to build secret block chains that leverage the coin-days-destroyed of transactions in the public chain.
For an attacker to perform a brute-force double spend attack they must produce 7 blocks in secret while the rest of the network produces 6 blocks.
Once the attack was complete, the attacker will have to wait another year before they could reuse their $1.68 million in capital to attempt a second attack.
Another factor to Proof-of-Work based security is that for most crypto-currencies the mining rewards fall over time. When this happens the amount spent on securing the network relative to the value of the network falls. For example, assuming no changes in the value of Bitcoin, when the mining reward falls by 50% so does the security of the network. The value of the network must double to $24 billion to maintain the same level of security it has today after the difficulty adjustment.
Lastly, if a large double-spend did occur everyone on the network would know and in theory could cooperate to add more proof-of-stake to the weaker chain with your original double-spend.
Unlike Proof-of-Work systems, it is very easy for a few honest nodes belonging to large stake holders to act as guardians of the chain. When they see an attempted double spend attack they can use their own savings to squash the attack in minutes.
Lastly, given the cost of a double spend attack, the reality that such an attack would significantly reduce the value of the coins, and the difficulty in performing large double spends anonymously it becomes clear that the attacker would lose more value in depreciation of their assets than they would gain if they were successful.
Anyone with that kind of money would not bother attempting a double-spend over anything trivial. Therefore, I submit that for most ordinary transactions a double spend is very unlikely and the losses from such a double spend attempt would be minimal. Furthermore, the attacker could only perform it once per year.
Unlike Bitcoin where your confirmation time is entirely dependent upon miners finding blocks, someone wishing to accelerate the confirmation time of one transaction can do so by confirming it with some of their own coin-days.
Offline Transactions would not necessarily have access to the current head of the block chain at the time they are signed. Therefore, they would be unable to verify the current head block at the time they are signed. The only coin-days that count for the purposes of the transaction are those between the output and head block included in the transaction.
Under our approach, transactions that migrate from a minority fork would not contribute to the coin-days-destroyed. This will insure that chain forks do not require individuals to re-issue transactions.
The next challenge is to decide who gets to broadcast the block when all nodes could generate the new block at the same time. We propose that the owner of the single input that destroys the most coin-days of all transactions in the block is the only one who may broadcast the block. This owner will sign the block header and broadcast the block. If someone else would like to compete to decide the block they must destroy more coin- days which effectively bids up the cost of earning the right to produce the block and in the process increasing the security per block.
We suspect that there is ample opportunity for speciality algorithms to be developed that could earn block creators some revenue for securing the network with their stake. These same algorithms would likely also defend the network against double spend attacks when ever they are observed.
The techniques presented solve the 51% attack, the selfish-miner attack, and provide protection against double-spending all while requiring no mining at all.
I mostly enjoyed the paper, thanks for writing it. There was, however, something that actually upset me about it, and that was the complete lack of references and citations. That is simply unacceptable for this type of document, and left me with a bad taste unfortunately.
I mostly enjoyed the paper, thanks for writing it. There was, however, something that actually upset me about it, and that was the complete lack of references and citations. That is simply unacceptable for this type of document, and left me with a bad taste unfortunately.
+5% I agree. I understand that development is probably a higher priority than formal documentation of the ideas, but before too long (probably not before BitShares XT launches, of course) this document should be updated and significantly formalized to include a good set of citations.