Bitcoin Markets Blog

GHash.IO recently crossed 50% of the network hashrate spurring concern of a 51% attack.  Most core developers and bitcoin veterans have said that this is nothing to be concerned about since the 51% attack is only theoretical and in practice, the mining pool with 51% has a much greater incentive to continue mining honestly and reaping the benefits of the block rewards and transaction costs rather than completely undermine the network for a double-spend.  For a double-spend to be worth it, the size of the transaction must be of a magnitude greater than the discounted future value of honest block production over the course of bitcoins future life.  For all practical purposes, it is extremely unlikely for this situation to arise.  It's also worth remembering that a 51% attack does cannot create coins out of thin air or manipulate ledger balances, it only allows for double-spending with inevitability (i.e. inevitably the 51% pool can outrace the rst of the network in block production in the long run).  I agree for the most part with this assessment.  However, I am still uneasy because a pool having 51% of the network hashrate causes the bitcoin protocol to become more "fragile", in the Nassim Taleb sense.  Should the 51% pool get hacked or seized by some malicious actors, the normal and rational incentives of the pool operator may not matter.  On the bright side, any evidence of an actual double-spend would cause many pool participants to leave the pool so even in the worst of the worst cases I don't see more than a few double spends happening.  In fact, the reason why GHash.IO can't maintain 50% of the network hashrate is because every time it crosses 50% or gets close, many pool participants leave of their own volition.

In Gavin's recent post, he begins by saying that although Ethereum has some great properties like funds bound to contracts, arbitrary code and state, it's complexity may be unnecessary and ultimately lead to security problems.  Instead he suggests a sort of bit-thereum whereby many of Ethereum's good features can be implemented on top of the bitcoin protocol so long as we permit contract verification by a set of semi-trusted oracles instead of the entire network.  Since most interesting contracts would require data from outside the blockchain(bitcoin)/blocktree(Ethereum) anyway, even an Ethereum system would require trust at some point to arbitrate these types contracts (e.g. contracts based on the price of bitcoin on an exchange).  So the only real loss in having a bit-thereum oracle system instead of Ethereum would be the requiring of trust to verify contracts which are based entirely within the blockchain (e.g. contracts based on bitcoin transactions from address to another).  Gavin goes on to talk about incentive structures for the oracles and for those using the oracles.  You can read more about it here: http://bit.ly/TUvoBl.  Also check out RealityKeys for automated oracle systems and dispute mediation (http://bit.ly/1qddVkX), Orisi for distributed oracle systems for cryptocurrency contracts (http://bit.ly/1uqou1V), and Truthcoin for decentralized bitcoin prediction markets (http://bit.ly/1iirA14).