Majority is not Enough: Bitcoin Mining is Vulnerable

[solex]

obvious troll is obvious guys

[1714699438]

1714699438

[1714699438]

1714699438

[1714699438]

1714699438

[gmaxwell]

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

I am an organization now? Awesome. Do I get to have a charter?

What does this have to do with Luke's comment?

[Luke-Jr]

Which is fine so long as Bitcoin's central bank's client

Huh?

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

Only if you let/make us.

[CanaryInTheMine]

Which is fine so long as Bitcoin's central bank's client

Huh?

You are surely aware that the organisation that controls (writes and maintains) the Bitcoin client used by the majority basically controls Bitcoin.

I don't know how to comment without being rude... So I won't... Ugggg

[gyverlb]

I'm surprised you don't have this guy ignored already. Typical "everything about bitcoin is bad but I'm not going to understand what I am talking about" troll.

Now back to something interesting, like GBT. I didn't know you could use it to also push the block to the network yourself. Genius.

p2pool has a similar approach with a nice tweak. A node finding a block obviously pushes it to the network as expected from a distributed pool. The nice tweak is that the protocol between p2pool nodes speeds up the distribution of blocks between them and each p2pool node relays the block to the Bitcoin network : p2pool is essentially broadcasting its blocks from all miners in a very short delay.

I've always wondered if p2pool has the fastest publishing method of all pools (I'm optimist but it depends on the actual node finding the block and each node connectivity obviously). If you look at the number of addresses mining on p2pool you can have a rough estimation of the number of active nodes (many use the standard "one node <-> one address" setting) and the number of p2pool block distribution points.

[Meni Rosenfeld]

My thoughts on the matter:
http://fieryspinningsword.com/2013/11/06/hashrate-amplification-attacks/

[niniyo]

Would it be possible to reduce the centralised power from large pools through the following method?

- The pool simply provides the miner with the pool's payout address
- The miner can build whatever block they want, so long as it contains a coinbase output which pays the pool with amount (BLOCK_REWARD - MINER_BONUS).
- The miner bonus is a second output added to the coinbase transaction which the miner can pay to him/herself.  It could be 1% of the block reward or something like that.  This gives the miner a direct financial incentive to publish blocks they find immediately.
- The pool accepts the work from the miner so long as it contains the coinbase transaction that pays the pool.

* Possibly there could be some variation on this protocol so that the miner doesn't have to track transactions and build their own merkle tree.  Eg. the pool operator could provide a suggested merkle tree to the miner, and the miner just has to communicate any desired changes back to the pool operator, which reduces the bandwidth required.

[Luke-Jr]

Would it be possible to reduce the centralised power from large pools through the following method?

- The pool simply provides the miner with the pool's payout address
- The miner can build whatever block they want, so long as it contains a coinbase output which pays the pool with amount (BLOCK_REWARD - MINER_BONUS).
- The miner bonus is a second output added to the coinbase transaction which the miner can pay to him/herself.  It could be 1% of the block reward or something like that.  This gives the miner a direct financial incentive to publish blocks they find immediately.
- The pool accepts the work from the miner so long as it contains the coinbase transaction that pays the pool.

* Possibly there could be some variation on this protocol so that the miner doesn't have to track transactions and build their own merkle tree.  Eg. the pool operator could provide a suggested merkle tree to the miner, and the miner just has to communicate any desired changes back to the pool operator, which reduces the bandwidth required.

This is essentially what GBT aims to do.

[niniyo]

This is essentially what GBT aims to do.

Oh, I just read https://en.bitcoin.it/wiki/Getblocktemplate in more detail and I see what you mean.  At first I thought it only gave miners a read-only view of the pool's block.

This is would be fantastic to roll out.  I suppose a miner bonus scheme would not be enough to attract people to new GBT-based pools because your expected returns would be the same in the long run, in fact it just adds more unwanted variance, but there are other advantages like the small chance of mining one of your own (or your friends') transactions with 0 fees if you somehow integrated your wallet with your mining rig.

I hope miners make a sensible decision and require GBT with full ability to modify the merkle tree + miner bonus to incentivise immediate publishing of blocks.

[Enochian]

http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/


Posted on Monday November 04, 2013 at 03:10 PM by Ittay Eyal and Emin Gün Sirer

Bitcoin is broken. And not just superficially so, but fundamentally, at the core protocol level. We're not talking about a simple buffer overflow here, or even a badly designed API that can be easily patched; instead, the problem is intrinsic to the entire way Bitcoin works. All other cryptocurrencies and schemes based on the same Bitcoin idea, including Litecoin, Namecoin, and any of the other few dozen Bitcoin-inspired currencies, are broken as well.


I wonder if they've already added "broke Bitcoin" to their resumes.

[bee7]

http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/

From your perspective, if the Bitcoin community does not buy your bug fix,

you would be incentivized to selfish mine yourself and reap the benefits.

Do that and prove that Bitcoin is fragile. If it really is, then a newer, better one will appear.

If you do not do it, it means you're a fraud.

+1

[Gavin Andresen]

I have done some financial analysis to see how fast an attacker can get benefit from this attack. Let's the total network hashing rate is stable. At the beginning of the attack, he will always loss some mining revenue as the diff is fixed and he will lose some blocks when he is trying to broadcasting his double blocks. And his attack will make the growth of blockchain slow.

If the attacker owns 30% of the network hashing power, according to the formula of on the paper ten, he will make the blockchain grows 1.8x slower than if not attacked. Assuming 50% of the block attacker broadcasts accepted,  The revenue speed of the attacker will be influenced. He will loss 40% of his revenue if he had not attack, which is to make other honest miner mine even less and more slower. If the attack continues to next diff period, the attacker start to enjoy the benefit. He will earn more than 9% if he had not attack.


The attack invest 1.8*14=25 days time and 40% of the mining revenue (3600*25*30%*40%=10800 BTC, assuming still 25 btc per block), and he can earn more than 100BTC everyday, which earns investment in 111 days, during which time the whole community finds out his naughty behavior and make a hard-fork.

So, not a very wisdom attacker.

Please check whether my logic is right or wrong by independent calculation. Assuming the total net work hashrate is stable to make analysis simpler. First the attacker has to invest time and losing mining revenue to slow down other people, however the diff is fixed during the time, he is losing money to attack the network. The chain will grow extremely slower during the attack. The attacker suffers with other honest miner together, much longer than 14 days. If he is wealth enough and willing enough, Diff lowers, and he starts to harvest the benefit.  However, the time to make his investment back is very long, and before he can earn back his investment, the community will have already make a hard-fork.

+1

This is the kind of analysis that I think we need more of before jumping to the conclusion that there is actually a problem that needs to be fixed. I'm not claiming that HorseRider is correct, but his logic looks plausible and I tend to listen harder to reasonable people who say things like "please check whether my logic is right".

[kjj]

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.

Please do run your simulations.  When you do, make sure that you faithfully simulate a network with latency.  The word latency exists in their paper exactly one time, as a casual aside in the solution section, which should immediately set alarm bells ringing in all of our heads.  In addition, they seem to suffer from the strange notion that work in bitcoin can be wasted.  Despite the fancy pedigree of the email address in the page footer, I suspect that their paper has more to do with hubris, ignorance of physics and a serious lack of understanding of how bitcoin really works.

Let me start with latency.  As far as I can tell from the paper, their "simulation" (and here you should imagine me doing very sarcastic air quotes) involves a network where the evil miners have magically found a way to detect the competing block in the honest miner's memory, before it has begins to spread on the network.  Gamma seems to play some sort of role here, but the meaning of it seems to change from page to page.  Or at the very least between pages 8 and 11.  Can anyone give me a good justification for abusing this poor variable in this way?

The charts are very illuminating.  In figure 2, each of the simulation points is exactly on the calculated line.  This is a dead giveaway.  The only way that can happen is if their model is fully deterministic except for mining function.  Amusingly, in a universe without latency in any form, which is the only universe where this model is meaningful, their solution is unnecessary, and actually counterproductive (since it causes the problem they aim to solve).

The real gold of this paper comes on page 13.  On page 13 they handwave over the latency issue by pointing out that an attacker could insert itself between every other node on the network.  Let me just sum up a few years of discussion on this topic:  We Know.  If an attacker is able to isolate a single node, they can fuck with that node.  If an attacker is able to isolate every node (lol), they can fuck with every node.  Note to researchers:  If anyone can control the spread of information across the entire network, they don't need whatever crazy scheme you've cooked up; they can already do much worse things.  In particular, if an attacker is capable of creating the conditions necessary for this garbage to work, they can just not forward any blocks but their own, and they multiply whatever skimpy hashing power they have by infinity and they gain total control over all mining.

Of course, everyone instantly sees how silly that is, so they had to dress it up in pseudo-scientific gibberish so that people would click on their crappy website and check out the douchebag's glamour shot.

Sigh.  Is there even any point in addressing point two now?  Work is not cumulative.  Publishing a block does not make the rest of the network "start over".

[Enochian]

From your perspective, if the Bitcoin community does not buy your bug fix,

you would be incentivized to selfish mine yourself and reap the benefits.

Do that and prove that Bitcoin is fragile. If it really is, then a newer, better one will appear.

If you do not do it, it means you're a fraud.

+1

The researchers just did a massive delete of critical comments from their blog posts.  At this point, they are really embarrassing their institution by overstating their results, and refusing to listen to reason.

It reminds me of the guy at HP, Vinay Deolalikar,  who "proved" NP!=P in August 2010, and then totally closed his mind to any suggestions that his chain of reasoning had some missing links.  His Web page still claims the result.

Some people.

[cunicula]

I have done some financial analysis to see how fast an attacker can get benefit from this attack. Let's the total network hashing rate is stable. At the beginning of the attack, he will always loss some mining revenue as the diff is fixed and he will lose some blocks when he is trying to broadcasting his double blocks. And his attack will make the growth of blockchain slow.

If the attacker owns 30% of the network hashing power, according to the formula of on the paper ten, he will make the blockchain grows 1.8x slower than if not attacked. Assuming 50% of the block attacker broadcasts accepted,  The revenue speed of the attacker will be influenced. He will loss 40% of his revenue if he had not attack, which is to make other honest miner mine even less and more slower. If the attack continues to next diff period, the attacker start to enjoy the benefit. He will earn more than 9% if he had not attack.


The attack invest 1.8*14=25 days time and 40% of the mining revenue (3600*25*30%*40%=10800 BTC, assuming still 25 btc per block), and he can earn more than 100BTC everyday, which earns investment in 111 days, during which time the whole community finds out his naughty behavior and make a hard-fork.

So, not a very wisdom attacker.

Please check whether my logic is right or wrong by independent calculation. Assuming the total net work hashrate is stable to make analysis simpler. First the attacker has to invest time and losing mining revenue to slow down other people, however the diff is fixed during the time, he is losing money to attack the network. The chain will grow extremely slower during the attack. The attacker suffers with other honest miner together, much longer than 14 days. If he is wealth enough and willing enough, Diff lowers, and he starts to harvest the benefit.  However, the time to make his investment back is very long, and before he can earn back his investment, the community will have already make a hard-fork.

+1

This is the kind of analysis that I think we need more of before jumping to the conclusion that there is actually a problem that needs to be fixed. I'm not claiming that HorseRider is correct, but his logic looks plausible and I tend to listen harder to reasonable people who say things like "please check whether my logic is right".

Check, HorseRider is correct.

I would add that there is no guarantee that the selfish pool which invests to lower difficulty is the same selfish pool that reaps the reward from lower difficulty.

Once you treat the game as dynamic (which it is in reality), the attacker faces a free-rider problem.

[Luke-Jr]

Fresh coindesk article summarizing the situation

http://www.coindesk.com/bitcoin-mining-network-vulnerability/

Unfortunately, it seems to get many facts wrong too...

• The timestamp in the block header is entirely ignored, and the block-discovered-first isn't reported at all (nodes know which they saw first, and that's all they care about)
• No mention of the fact that there are many better sybil attacks should sybil-ing be possible.
• The proposed solution doesn't limit pools to 25% (this isn't even theoretically possible).

[btcdrak]

Fresh coindesk article summarizing the situation

http://www.coindesk.com/bitcoin-mining-network-vulnerability/

Unfortunately, it seems to get many facts wrong too...

• The timestamp in the block header is entirely ignored, and the block-discovered-first isn't reported at all (nodes know which they saw first, and that's all they care about)
• No mention of the fact that there are many better sybil attacks should sybil-ing be possible.
• The proposed solution doesn't limit pools to 25% (this isn't even theoretically possible).

Sounds like someone needs to tell coindesk how badly wrong they got this...

[hannesnaude]

This paper is game theory fail.

Fail A
1) The benefit from selfish mining comes from future reductions in difficulty.
2) Until the reduction in difficulty happens, the selfish miner (like other miners) incurs losses.
3) Once difficulty falls, the lower difficulty is open to all. Some other selfish pool could step in and reap all the benefits. Socialized gains; private losses (and socialized losses). Doesn't seem rational unless you have some reason to believe that you can beat pools that copy the strategy. If you try to do the strategy and succeed in lowering difficulty, but ultimately some other pool comes out on top, then you will take losses.

Don't quite agree with you here.
1)  Agreed
2)  Agreed. But it is important to note that the selfish pool suffers smaller losses than the others. Therefore rational wealth maximising agents who denominate their wealth in BTC would join this pool (were it not for your observation under Fail B which I will get to next).
3) The lower difficulty is open to all, but the other pools are still underperforming relative to the selfish pool. Rational miners still join the selfish pool. It is entirely possible that another selfish pool starts up, but far from being a threat to initial selfish pool operator, it is actually the best thing that could happen to him. Since the gains grow superlinearly both pools will mine more coins by joining forces than they would have otherwise. This process runs away and leads any pool  that starts with >33% to end up with >50%, at which point the classic 51% attack becomes possible.

Fail B
Some pools offer PPS. As long as these pools commit to keep up their PPS scheme, miners will migrate to these pools in the event of the attack. This causes the attack to fail. Sure the PPS pools bleed coin in the beginning, but in the end they end up with more miners and the attack gets resolved. If you put this in a economic model with switching costs [i.e. people stay at a pool unless there is a significant benefit from switching], the attack is a probably a net win for the honest PPS pools.
To retain miners, the attacker would need to switch to a PPS system as well. But then he is essentially creating bad luck and insuring people against it simultaneously. This attack is a surefire way to bleed coin.

THIS is a critical observation, which I have not thought of or seen mentioned elsewhere.  Essentially PPS can invalidate the entire attack, since a rational miner would rather join a PPS pool, where he will earn even more income than from joining the selfish pool. One can reason that the PPS operator, (who takes the hit for all of the orphaned blocks) will cancel the service or put the price up enough to compensate. But this means that the attacker first needs to keep the attack up for long enough to drive all PPS operators out of business. Only when this is complete will rational miners flock to join the selfish pool. This makes PPS operators vulnerable to this attack, but it is not very different from the well known block-withholding attack that they have always been vulnerable to, in fact it is a little less serious since it can easily be detected. Also, if someone with deep pockets (Bitcoin Foundation? BTC guild?) publicly commits to keep at least one PPS operation afloat for the duration of any such attack, then the selfish pool attack suddenly becomes very unattractive indeed, since you need to incur a sustained loss (relative to what you could have earned with the same hashing power at a PPS pool), and only if you can sustain this loss for longer than the PPS operators can sustain the loss you are inflicting on them can the attack actually start recruiting other rational miners to help you. This is somewhat analogous to trying to enter a new market against an entrenched competitor who is committed to a strategy of predatory pricing i.e. they will sell their products at a loss until you eventually go bust or leave the market.

Combine this with Fail A and you can see that the entire paper is fail.

I actually think the paper is quite good. The attack is quite unlikely to work in practice, but the theory is incredibly important. The result  is counterintuitive, but undeniably correct. I've done my own calculations and simulations and arrive at the same results as they do. Some claim that the attack was known before, but I am afraid none of the rather vague hand-waving explanations of a mining cartel attack has managed to convince me that this is possible. The fairly basic math used in the paper convinced me in less than an hour.

[jl2012]

This process runs away and leads any pool  that starts with >33% to end up with >50%, at which point the classic 51% attack becomes possible.

So that's the 51% attack mentioned in Satoshi's paper. I can't see any originality here

[cunicula]

You need to model this as a dynamic game with entry and exit. They do not do this. The methodology is inappropriate to the problem at hand. They are not qualified for this. This is an industrial organization problem, not a computer science problem.
Done appropriately you would almost certiainly end up with multiple equilibria and sensitivity to assumptions about entry costs for pools and switching costs for individual miners. Game theory tells you very little of use for these types of problems.

In any case, this is all artificial since there are ways of achieving the same aim without any upfront cost. It is hard to sensibly analyze a costly attack approach when cost-free attack approaches that achieve the same aim are available.

Consider a loyalty program where you record each worker's cumulative contribution to the pool. In the event the pool acquires 51%, you divide the 50% of surplus attack revenue according to some function of current hashing power and historical contributions. The loyalty program has no upfront cost at all. As long as the attack has a nonzero chance of succeeeing, the dominant strategy is to always join the pool. The more people join the more attractive joining becomes.

Why would you pursue a risky convoluted attack strategy that requires upfront investment and only works under arbitrary assumptions about barriers to entry. The strategy I suggest is essentially risk free. No upfront investment needed. Since there is no cost to attempt the loyalty program attack, it is worth attempting even if it has a miniscule chance of succeeding.