Topic: Majority is not Enough: Bitcoin Mining is Vulnerable - page 11. (Read 51020 times)

Point 0 is just a workaround right?

I'm short on time, and this was announced to the public without advanced notice to e.g. the bitcoin-security list. Making an informed response fast is hard.

Ideally I'd like to think about it carefully, read the paper a few times, and run some simulations before commenting, but I'll likely be tied up at the IETF all week and people are already panicking and pushing for hasty changes in response to this which may be ill-advised, so I'm going to offer some preliminary comments here.

We've (or, at least, I have, see also Bytecoin's analysis in 2010) evaluated this general attack before but the simplest version of it just doesn't work out (in theory, or in simulation): Without significant hash-rate delaying your blocks ends up increasing the risk that you get orphaned since nodes prefer the first block they heard. The contribution of the paper (to my thinking, at least) is to assume that an attacker can also sybil attack the network, and in doing so can run nodes which will release blocks produced by the attacking miners in response to hearing a new block from the honest miners. So where the sybil attack is successful the delay does not confer a disadvantage and then the attack works (with increasing effectiveness the more effective the sybiling is and the more hashrate the attacker has).

Their proposed solution, which is offered without extensive analysis, is to relay all blocks, even late ones, and then choose the preferred block in ties at random. Ignoring collateral vulnerabilities which a hasty implementations of forward-all might create, I believe this proposal has a problem in that it creates a selfishness advantage even without any sybil attack at all, so long as the selfish miner has enough hashrate.  I believe this is a bad tradeoff because the degree of sybil vulnerability between mining nodes is likely much lower than assumed (many miners pin up connections to well known nodes and each other), and because we already have pools large enough to take advantage of the tradeoff vulnerability this creates.

Perhaps more importantly:  There are much worse vulnerabilities for us if attackers can perform successful large scale sybil attacks against miners.  In particular, if they're able to do that they could partition the network into two 50/50 hashrate groups and then drop blocks between them and hand conflicting transactions to each group and produce many-confirmed double-spends without having any hashrate at all.

As I've posted several times of Bitcointalk: beyond the cryptographic assumptions Bitcoin makes _two_ additional security assumptions: That an attacker doesn't control a majority of the hashrate and, quoting Satoshi, "the nature of information being easy to spread but hard to stifle", effectively— that an attacker can't substantially isolate or partition the honest participants.

With this in mind, rather than rushing in any changes in the consensus algorithm I recommend we take the following actions:

(0) Make a new concerted manual anti-sybil effort to ensure that all large miners are well connected to strong relaying nodes, including a mixture of public and non-public nodes (non-public for DOS resistance), in order to make partitioning miners infeasible.
(1) Evaluate our sybil resistance more generally and consider what measures and automation we could add to make sybil attacks harder (including supporting authenticated peering, or measures like including addr messages in coinbase txns to jam addr message manipulation).
(2) Build better stats collection for monitoring network wide orphaning.
(3) Improve node scalability (e.g. make it possible to support nodes with larger numbers of connections)

(Maybe it would also be useful to instrument miner software to detect block delaying, in the same way bfgminer will detect a pool issuing work that conflicts its own prior work)

It may ultimately make sense to change the consensus preference for _very_ near ties (e.g. ones which arrive with time differences comparable in scale to the difference in latency between your peers), but I think we need to be very careful that we don't trade a potentially irrelevant problem (because its either infeasible or if its not infeasible we have much worse problems) for a practically exploitable one.  Making our infrastructure stronger against sybils has many benefits and has been on and off the radar for a long time, and AFAICT if we prevent miner from being partitioned/intermediated by sybils we close the concerns here.

Thoughts?

I didn't read the maths carefully but I think I read something similar before. I don't think it works in a very effective way as the reason stated in section 6.1. The sybil attack described is also not effective if there are many honest full-nodes. Also, I assume that big pools are connected directly to minimize the stale rate so again such sybil attack won't work.

There are also other solutions, such as forwarding unverified full difficulty block headers, or even partial difficulty headers.

No, completely wrong. The article is talking something else, and at the same time your strategy does not work at all.

This is a very common noob misconception. Simply speaking, a "share" is bound to the destination of the reward so you can't direct the reward to other address.

Fascinating...reading still right now...but if I get this correct - the concept is that you're mining on something big like btcguild, and copying the entire block header onto your own private pool of work; at the same time, your miner is accepting work and not submitting valid shares to btcguild yet it submits them to the private duplicated pool. 

Anytime a Valid Share is found to have met minimum difficulty and discovers a block, it submits this from the private pool and broadcasts to the network?  Network accepts this and the private pool is fed the newly minted coins instead of btcguild?

Saw this on reddit first, reading paper, thought I should share:

http://arxiv.org/abs/1311.0243

http://www.reddit.com/r/Bitcoin/comments/1puk1a/arxiv_paper_majority_is_not_enough_bitcoin_mining/