How to double spend PoW coins for fun and profit.
You don’t even need major pools to subvert the security of the blockchain and double spend.
Let’s say that you want to doublespend a transaction that was included at height H. Simply put out a bounty for more than the mining reward for the first miner to mine an alternative block at height H. Then, you reward the (traitor) miner on the existing blockchain. As long as the instigator is trustworthy, rational greedy miners would switch because the expected reward is higher. Then you do the same for height H+1 and so on, until the fork wins.
Jae also had some more comments related to blockchain forks and he gave me permission to have them reposted:
I actually wrote a prototype of an exchange engine, and the hardest part was dealing with logic pertaining to block chain forks. It’s just so easy to get wrong, and it’s not even clear when a transaction should be deemed “irreversibly committed”. So I ended up having to write tricky edge cases, where, I can imagine bugs can emerge. This isn’t something that will connect with most users, so I doubt that people will even “get it”, but my assessment is that Bitcoin has these fundamental design issues that may end up hurting its adoption rate compared to other designs..
Another thought is that we probably want to see a multi-coin future where no single coin has global dominance. If you want a future with many multiple competing cryptocurrencies, then you probably want to get away from a consensus algorithm that relies on energy.
I don’t know enough about BitShare’s DPOS scheme to list specific vulnerabilities, but here’s a rule of thumb that I use to evaluate consensus algorithms:
The amount of value at stake that is lost in the event of a fork is roughly the amount of security afforded.
In the PoW vulnerability that I mentioned, what is at stake is the electricity spent mining blocks. Large transactions need to be vetted by waiting a proportional amount of confirmations, potentially much longer than the original 6 confirmations as cited in Satoshi’s paper for transactions over hundreds of BTC.
In any delegated PoS model, if Carl can delegate his stake to someone without the risk of losing that stake, then Carl can be bribed by Malory to delegate his stake to Malory’s puppet account. On the other hand if Carl can lose his stake in the event that the delegated signer does something bad (e.g. enable a double spend by forking the blockchain), then Carl probably wouldn’t want to delegate his stake to anyone, and instead would opt out of the consensus process or become a validator himself. For this reason I don’t find delegation models to be very interesting. It may provide some utility as long as delegated coins are “at stake”, but the foundational consensus algorithm (minus the delegation part) must be secure first. Delegation cannot fix a broken algorithm.
Lastly, Peter Todd suggested that I emphasize that there is a difference between hard forks, soft forks and SPV soft forks. Last fall Todd wrote an overview on this titled On soft-forks and hard-forks.