I thought I would comment on this, purely from a constructive perspective, with the goal of keeping the Bitcoin protocol, as it was proposed by Nakamoto in the original paper.
With regards to the web article you posted (
http://hackingdistributed.com/2014/06/16/how-a-mining-monopoly-can-attack-bitcoin/)
Note the article is written by Eyal, I. and Sirer, E., the authors of the paper
Majority is not Enough: Bitcoin Mining is Vulnerable (2013). Available from:
http://fc14.ifca.ai/papers/fc14_submission_82.pdfSelfish miner attack is not really an attack on the Bitcoin Protocol, more a means to attract more people to a specific mining pool and perhaps increase earnings. I would perhaps agree that this could be seen as an attack on Bitcoin mining pools in general as a way to manipulate miners into joining the pool after manipulating pool shares making that pool appear more attractive from a revenue perspective.
I am not sure if you read the proposed solution by Eyal and Sirer for the selfish miner problem, you would see the solution is not move to a central authority, but rather a backward compatible solution that does not impact how Bitcoin operates, or how pool mining operates.
There are other ways to manipulate miners to join a pool, namely with lower fees, incentives (like block discovery as suggested by Nakamoto), cooler dashboards, etc.
With regards to double-spending, surely this is only feasible with "Fast Payments," like described by Karame, Androulaki and Capkun in their paper Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin (2012)?
So worst case you could theoretically double spend if the merchant allows fast payments, like any corner shop where you would buy coffee. I am very intrigued by Nakamoto's suggestion to solve this issue:
"I believe it'll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.
The network nodes only accept the first version of a transaction they receive to incorporate into the block they're trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it's a race to propagate to the most nodes first. If one has a slight head start, it'll geometrically spread through the network faster and get most of the nodes."I believe that these are already in place.
With regards to the 51% attack, you are suggesting moving to a central authority to resolve. This central authority would then be the trust authority, to verify no tampering with the transactions, etc. The Conclusion of the Bitcoin paper starts with:
We have proposed a system for electronic transactions without relying on trust.
Surely a far simpler solution from you, if you are concerned about the selfish miner and the 51% attack, would be to propose an end to pool mining? Pool mining could be viewed as some form of attack vehicle on the Bitcoin protocol because it makes both 51% attack, selfish miner a possibility, and potentially the double-spend GHash.IO is accused of. With regards the GHash.IO double spend, I have not researched that yet, but it is on my list of things to research for my thesis.
Bitcoin is also still under development, there will be issues, and as they present themselves the developers will resolve them. If anyone chose to invest in a BETA program they can expect bugs. I would propose technical solutions to technical problems, not regulation which goes against the principle/spirit of what Bitcoin is. Just my 2 cents.
It comes across that your interest in Bitcoin is purely financial (whereas mine is purely academic). I apologise if I have the incorrect perspective.
bitcoin doesnt do double spends..
sorry but bitcoin is double spend protected by default.
now if a mining pool was to do a 51% to mess with the code to attempt to inject new coins. then those coins would be rejected by our nodes as the miners rules dont match our nodes rules.
secondly if it was to try a double spend of existing coins only the merchant receiving the coin would be at risk and not the entire bitcoin circulation. thus businesses would choose if they wanted their customers real life details or not. there is no need for a world ID. its much more simpler for a bitcoin business to ask for someones passport number or social security/national insurance number.
I just want to point out to the original paper, in the introduction on page 1, when Nakamoto is referring to the currently used trust based systems and reversible transactions:
With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need.Bitcoin is meant to solve this isn't it so I don't see this a solution at all, but rather detracting of what Bitcoin is.