Majority is not Enough: Bitcoin Mining is Vulnerable

probability of selfish mining [1]. The authors of [0] prove that for Bitcoin, under some assumptions about the maximum delay an adversary can use and the block production rate, is consistent because it has both a lower bound on how much chains between different participants can differ as well as an upper bound about how far ahead a single participant can grow their chain. Note that all of these statements have to be interpreted as statements "with high probability" relative to security parameters. In [0], the authors argue that Bitcoin, in particular, is a partially-synchronized global clock, and they take advantage of it in [2] to make a hybrid blockchain-DB system that provides more traditional eventual consistency guarantees. NOTE: I'm not an author of any of these papers, just a casual observer [0] https://eprint.iacr.org/2016/454.pdf [1] https://arxiv.org/abs/1311.0243 [2] https://eprint.iacr.org/2016/917.pdf

and Andrew Miller et al [3] came up with techniques based on non-outsourceable puzzles. This is a cool technique that would make it difficult for miners to run large open pools. It does require a potentially disruptive change to Bitcoin, so it's good to have in one's back pocket if the mining situation gets out of hand, but it's not something you want to deploy. Luckily, Ittay's subsequent work on the Miner's Dilemma [4] discovered an incredibly interesting result: it pays for miners to attack other miners who are running large open pools. This puts natural pressure on miners to not open themselves up to the public and accept people into their pools willy nilly. This in turn is, I think, fantastic news, as it means that the problem may take care of itself, at least when it comes to open pools. Overall, the distribution of mining power is a point of concern for everyone in the Bitcoin space. The situation looked bleak at first, as it looked like there were few mechanisms to keep open pools from growing ever larger. But now we have a strong technical solution and a natural process that is well-characterized. Large solo miners still remain an ongoing concern. Hope this is useful. [1] http://arxiv.org/abs/1311.0243 [2] http://hackingdistributed.com/2014/06/18/how-to-disincentivi... [3] https://cs.umd.edu/~amiller/nonoutsourceable_full.pdf [4] http://hackingdistributed.com/2014/12/03/the-miners-dilemma/

breakeven thresholds with regard to 'override success' ('gamma'), very similar to your paper's calculations. That's why I credit your paper for rigorously describing the situation, under your specific assumptions, but not with the discovery of a previously-unknown less-than-51% attack. Also, your final paper is simply lying when it says the thread "does not suggest a solution to the problem". It's almost as if your disdain of these 'fringe' Bitcoin fanatics has blinded you to the actual words of the thread. Two commenters in the December 2010 thread (btchris and RHorning) suggest that preferencing accurate-seeming timestamps can disadvantage cartel-delayed blocks. That countermeasure is likely stronger than your paper's proposed random-choice-between-ties. (Randomization, by pushing gamma to 1/2, could make things worse if, on the real network, the effective gamma for late-releasers was already closer to 0. Preferring realistic timestamps, meanwhile, almost always helps 'honest' blocks, which don't have to guess a future time when they'll be released.) Note that the last bullet of supposed novelty in your paper – "defending against the attacker requires at least 2/3rds of the network to be honest" – is the exact same best-case threshold as reported by ByteCoin in thread message #36, 2010-12-14. He states: "a cartel with no preferential network access can be profitable with 33% of the generating power"[5]. Same result, 3 years earlier. How can you allege ByteCoin was simulating some other strategy? Wouldn't the slightest difference in block-release-rules result in a different best-case threshold? Finally, the Bitcoin Talk forums hadn't "CONCLUDED" anything. They're not a deliberative body. Some people were convinced, others weren't. The relevant actors – mining insiders – knew what they needed to know, to either try the attack, or detect it in orphan rates and weird timestamps... and to try countermeasures based on disadvantaging cartel blocks if ever necessary. Meni Rosenfeld also referred back to the matter as a known concern, in an answer on the Bitcoin StackExchange, in October 2011 [6]. So he knew it was an issue, and lots of people trust him about mining matters. There's no "brigade" out to trash you led by some "failed academic" "Singaporean" "ringleader". Your critics are not the heads of some unified hydra, that you can disregard altogether as the "Bitcoin lunatic fringe" based on a few quotes from particular yahoos. You've made specific claims of novelty, or doom, that were either never true, or disproven by later events. These will be pointed out when you claim to enjoy a "we told you so" record of authoritative insights. [1] http://arxiv.org/pdf/1311.0243v5.pdf [2] http://www.cs.cornell.edu/~ie53/publications/btcProcArXiv.pd... [3] http://fc14.ifca.ai/papers/fc14_submission_82.pdf [4] https://bitcointalk.org/index.php?topic=2227.0;all [5] https://bitcointalk.org/index.php?topic=2227.msg30138#msg301... [6] http://bitcoin.stackexchange.com/questions/1475/can-someone-...

>50% problem becomes the new lower bound for attackers, because with proof-of-work, you can't just fake 33% of the nodes. They have to be participating in the number crunching. However, recent research blew this entirely out of the water, at least as far as Bitcoin goes[0]. They propose a change to the protocol that makes it a >25% percent problem, but currently it is a >0% problem. That is kind of a big deal. There are some good ideas in the "proof of stake" discussions, but none of the answers appear to lend support to the "triangle is squared" hypothesis. Now then: I think you misunderstood my remark about the political aspects. I'm not saying anyone agrees on who/what/when/why/how of privacy issues. If the goal is to describe a system that is resilient to eavesdropping, you shouldn't distract from that system in the same paper with so much argument about why you want a system resilient to eavesdropping. Spill your ink to convince people if your system meets the requirements you lay out. Finally: - "meta-domain" is a very strange term to use. It makes you sound ignorant of the realities of DNS, whether you are or not. - My statement was that a proxy to namecoin doesn't add much to the system. The first and fourth of your bullet points might be paraphrased as "but it adds a proxy to namecoin!" - What would be the purpose of adding DNSCrypt to DNSNMC? What do you mean by "secure queries" there? Anonymous queries? Validated responses? It's okay if you haven't finished specifying DNSNMC yet, but I wasn't asking for guesses about what you might do in the future. Meanwhile, don't let counter arguments discourage you, but remember that the problem space is large. Failure to solve a gigantic problem may still be success when solving a normal sized problem. [0] http://arxiv.org/abs/1311.0243

transaction." The problem with 2PC is that a malicious node could stop somebody from being able to spend their coins by always sending nays out to the network when ever the victim sent a transaction. To prevent this, you would need to be able to detect when a node is faulty/malicious which would require implementing a costly Byzantine Consensus Protocol [1]. In practical systems that can withstand Byzantine faults, the number of messages required to agree on a log entry (e.g. a transaction) would be O(n^2) in the number of nodes in the network, which would greatly limit scalability. The genius of Bitcoin's Proof of Work protocol is that: 1) it is more resilient than Byzantine agreement. Byzantine agreement with 3f+1 nodes can handle at most f faulty nodes, while Bitcoin can tolerate 49% of the network hashing power being malicious. (though this is being debated currently due to theoretical strategies like selfish-mining) 2) it is much more efficient than Byzantine agreement in the number of messages sent, which has allowed the network to scale to thousands of nodes, although they have been running into issues with the blocksize/block limit, but their are currently research efforts [4] underway to remedy this. The main problem with Bitcoin's proof of work scheme it is that it is extremely expensive in terms of CPU cycles, but this is solved by compensating miners for their efforts through coin generation and transaction fees. [1] - http://www.cs.cornell.edu/courses/cs614/2004sp/papers/lsp82.... [2] - http://pmg.csail.mit.edu/papers/osdi99.pdf [3] - http://arxiv.org/pdf/1311.0243v5.pdf [4] - http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full...

rigorous proof yet that the selfish mining equilibrium isn't a real threat. If Bitcoin is The Way of the Future (I hope it is), we need to be sure about these things. Hand-waving statements about how Bitcoin isn't vulnerable because no one has found an exploit yet [5] are ridiculous and dangerous. [0] http://en.wikipedia.org/wiki/Paxos_(computer_science)#Byzant... [1] http://read.seas.harvard.edu/~kohler/class/08w-dsi/mazieres0... [2] http://research.google.com/archive/chubby.html [3] http://arxiv.org/pdf/1311.0243v2.pdf [4] https://freedom-to-tinker.com/blog/felten/bitcoin-isnt-so-br... [5] https://twitter.com/cdixon/status/412447615331360768