A new interview is up with IamSatoshi Network and Bitcoin core developer, Peter Todd.  While the first part explains the politics of getting code into (or out of the protocol) — which many enthusiasts gloss over — I especially found Peter’s discussions in Part 2 of germane interest due to the sky-is-falling on reddit surrounding Ghash.io the last few days.  Here is one such comment thread.  And I think this comment sums it up the best:

If a 51% can occur, all trust in bitcoin should be lost forever. An investment that relies on people begging random strangers on reddit not to ruin it every couple of weeks is not really something that seems like a great thing to pour actual money into, tbqh.

Tbqh means “to be quite honest” (that same user made other good points about this issue too).  And here is also another interesting subthread (mulligan for that decentralization + neutrality notion…).

Ghash.io is the largest mining pool on the Bitcoin network (it actually supports merged mining for Devcoin, Namecoin and Ixcoin as well) and it hit 48% of the network hashrate this past weekend (it is now 43%, see this chart).  Its parent operating company is Cex.io and the system is run in a cloudhashing manner — customers rent hashrate by purchasing contracts with bitcoin.  Interestingly enough, the cost of these contracts is now more than what you receive as a reward for hashing, leading to the joke that Ghash (and other such services) are pay-for faucets.  That is to say, faucets are way to distribute tokens, for free (usually by filling out some Captcha once a day).  Yet in this case, because of bitcoin volatility the past 5 months, users are actually paying to receive a minute amount of bitcoins — they might as well terminate their contracts and buy bitcoins on the open market.

One common refrain that some Bitcoin advocates say about mitigating 51% attacks is that hashers in mining pools can simply move and/or point their hashing equipment at another pool.  This may be possible in the “early” days of today, yet there are two problems as time goes on:

1) As we approach the top of the S-curve in ASIC tech improvements, mining farms (and pools) will gravitate to locations with the best and cheapest network and energy infrastructure.  This itself creates centralization risks that I and many others have written about.  If you are renting out equipment (hashing systems) from a cloud provider at one of these locations, you can no longer physically move the equipment to another farm and perhaps in some cases, you may not be able to direct your miner to other farms (there is one proposal by Greg Maxwell that hasn’t been reported on involving tamper resistant private keys physically built into the gear, but that’s a story for another post).

2) Block size increases.  In order to make the Bitcoin network more competitive as a payments and transportation network, there have been many proposals to increase the hard cap of 1 MB block sizes by several orders of magnitude.  To date however, the average block size is around 350 KB, with an average of 0.7 transactions per second — thus the need to increase it is low (primarily because few people actually use the chain for much activity such as commerce).  If block sizes are increased, without the use of something like tree chains, then centralization will occur because miners (and fully validating nodes) will need to pay for larger bandwidth options, larger hard drives, etc. which squeezes out marginal players.  This is a known issue but Peter Todd highlights this as a hurdle for hashers wanting to move to another pool for the same reasons mentioned in point #1.