Majority is not Enough: Bitcoin Mining is Vulnerable

[RodeoX]

If I'm reading this correctly, an attacker is more likely to loose value performing this attack than to profit from it. Is that right?

[1714675334]

1714675334

[1714675334]

1714675334

[1714675334]

1714675334

[Peter Todd]

I believe I have a simple and effective solution: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03137.html

Nope, that idea doesn't work: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03155.html

[zvs]

Makes it even easier when you have all these non-relaying nodes in the network and ppl falling behind several blocks.  Just add 70  more of those swiss nodes, gtg

[lenny_]

@OP:

That's why p2pool should be a solution. To prevent such things from happening in the future.

[Enochian]

I just printed out the paper and read it.

Since the algorithm for "Selfish Mining" is now public, all miners have an opportunity to employ it if they feel it gives them an advantage.  So the notion that there is only a single pool of colluding miners growing as other miners join it to reap its advantages is moot.

Initially the colluding pool is a small fraction of total hashrate, and therefore has a vanishingly small probability of being able to mine consecutive blocks on its private chain.  So the only thing it can do is force other people to waste time by delaying publication when it mines a block, and some fraction of the time, its block wins over the public block, and people who have attempted to append to that block lose their work.

This seems to me to be such a small epsilon in the hashing activity that no one is really going to care, and no one is going to bother to do Selfish Mining.  The work to reward ratio here is pretty large.

So basically, "Nothing to See Here," and no modification to the Bitcoin protocol is needed.

[Peter Todd]

Since the algorithm for "Selfish Mining" is now public, all miners have an opportunity to employ it if they feel it gives them an advantage.  So the notion that there is only a single pool of colluding miners growing as other miners join it to reap its advantages is moot.

With multiple competing selfish miners the one with the lowest latency network wins. Or to be exact, some function of lowest latency per dollar spent. Not unlike the race in high-frequency trading to get ever lower latency network connections.

Sticking our collective heads in the sand and singing la-la-la doesn't lead to solutions, something we may need some time in the future as the profit margins in mining become lower. There's a lot of people who should know better who keep on saying that miners have proven to be altruistic and interested in the long-term success of Bitcoin, but Bitcoin is much stronger if we don't need that tenuous assumption.

[justusranvier]

something we may need some time in the future as the profit margins in mining become lower.

Profit margins will go up when the transaction rate gets high enough to generate significant transaction fees compared to the block subsidy.

[Peter Todd]

something we may need some time in the future as the profit margins in mining become lower.

Profit margins will go up when the transaction rate gets high enough to generate significant transaction fees compared to the block subsidy.

a) mining is a zero-sum game

b) increased transaction rates mean more money spent on overhead, rather than the hashing power that keeps bitcoin secure

[justusranvier]

b) increased transaction rates mean more money spent on overhead, rather than the hashing power that keeps bitcoin secure

Yeah, well there's a huge amount of room for optimization there that currently isn't being done.

Either the transaction rate goes up high enough to pay for all this mining infrastructure or else Bitcoin dies.

[revans]

b) increased transaction rates mean more money spent on overhead, rather than the hashing power that keeps bitcoin secure

Yeah, well there's a huge amount of room for optimization there that currently isn't being done.

Either the transaction rate goes up high enough to pay for all this mining infrastructure or else Bitcoin dies.

And if you'd read and understood the paper you would know it is the latter; maths and human nature= bye bye Bitcoin. But fear not cryptocurrency cultists there are already a few hundred alternative ponzi scheme for you to get involved in.

[revans]

I just printed out the paper and read it.

Since the algorithm for "Selfish Mining" is now public, all miners have an opportunity to employ it if they feel it gives them an advantage.  So the notion that there is only a single pool of colluding miners growing as other miners join it to reap its advantages is moot.

Initially the colluding pool is a small fraction of total hashrate, and therefore has a vanishingly small probability of being able to mine consecutive blocks on its private chain.  So the only thing it can do is force other people to waste time by delaying publication when it mines a block, and some fraction of the time, its block wins over the public block, and people who have attempted to append to that block lose their work.

This seems to me to be such a small epsilon in the hashing activity that no one is really going to care, and no one is going to bother to do Selfish Mining.  The work to reward ratio here is pretty large.

So basically, "Nothing to See Here," and no modification to the Bitcoin protocol is needed.

Umm WTF are you talking about? Try reading it again, only this time whilst not high on Bitcrack. Maths + human nature= a selfish mining future and the end of Cultcoin. In a sense the popularity you so longed Bitcoin to have has destroyed it as peer review is demonstrating just how architecturally boken Bitcoin is.

[Peter Todd]

My ELI5 explanation that I posed to bitcoin-development might help people understand the attack:

Alice is a miner with some amount of hashing power. She has the ability to detect new blocks on the network extremely effectively because she has controls a lot of nodes with low-latency, high-bandwidth connections; in short she has unusually good knowledge of the state of the network. She is also very good at publishing her blocks and getting them to the majority of hashing power in very little time; she has unusually good connectivity to all miners. (again low-latency and high bandwidth)

She's so good at this that when she finds a new block, she keeps it a secret! She can get away with this because she knows that the moment any other miner, like Bob, finds a block, she can immediately broadcast it to the rest of the network before the other block propagates. Instead of building on Bob's blocks, almost everyone builds on Alice's block, having seen it first, depriving Bob of the revenue. Gradually Alice gets more and more miners because all the other pools don't pay out as much as Alice's pool does. This eventually leads to Alice having a majority of hashing power, or if not that due to social pressure, a majority of the mining revenue.

[eldentyrell]

your blocks ends up increasing the risk that you get orphaned since nodes prefer the first block they heard.

I think this assumption of theirs is the flaw.

Successful pools do not build on the first block they hear; they build on the most difficult block they hear.

If you rerun their calculations under that assumption, the cost of losing the work done on their second block in the private two-block chain swamps out any possible benefit.

If the end-user bitcoin-qt client is using the "first block heard" rather than "most difficult block heard", then it's a bug, and one that is already fixed on the network nodes that matter most for security (the mining pools and large solo miners).

Here is where they acknowledge introducing this bug in their simulation:

In the case of two branches of the same length, we artificially divide the non-pool miners such that a ratio of γ of them mine on the pool’s branch and the rest mine on the other branch.

[dree12]

your blocks ends up increasing the risk that you get orphaned since nodes prefer the first block they heard.

I think this assumption of theirs is the flaw.

Successful pools do not build on the first block they hear; they build on the most difficult block they hear.

If you rerun their calculations under that assumption, the cost of losing the work done on their second block in the private two-block chain swamps out any possible benefit.

If the end-user bitcoin-qt client is using the "first block heard" rather than "most difficult block heard", then it's a bug, and one that is already fixed on the network nodes that matter most for security (the mining pools and large solo miners).

Blocks that are not near a difficulty change will always have the same difficulty.

[eldentyrell]

Blocks that are not near a difficulty change will always have the same difficulty.

No, the difficulty of a block is binomially distributed.

The minimum difficulty required for a block to be valid is the thing that stays the same.  Within that 2016-block window the actual difficulty of various blocks varies above that threshold.

[justusranvier]

Blocks that are not near a difficulty change will always have the same difficulty.

No, the difficulty of a block is binomially distributed.

The minimum difficulty required for a block to be valid is the thing that stays the same.  Within that 2016-block window the actual difficulty of various blocks varies above that threshold.

It would be less ambiguous if you said, "Successful pools do not build on the first block they hear; they build on the block with the highest work they hear."

[eldentyrell]

The minimum difficulty required for a block to be valid is the thing that stays the same.  Within that 2016-block window the actual difficulty of various blocks varies above that threshold.

It would be less ambiguous if you said, "Successful pools do not build on the first block they hear; they build on the block with the highest work they hear."

Well, we're splitting hairs here, but technically I might have gotten lucky and not worked very hard to find a block whose hash, in binary, ends with 250 zeroes in a row (outrageously high difficulty).  "Difficulty" and "target" are actual technical terms with precise definitions in the block protocol.

But yeah we're talking about the same thing.

[Enochian]

Umm WTF are you talking about? Try reading it again, only this time whilst not high on Bitcrack. Maths + human nature= a selfish mining future and the end of Cultcoin. In a sense the popularity you so longed Bitcoin to have has destroyed it as peer review is demonstrating just how architecturally boken Bitcoin is.

Do you have a specific criticism?

You are welcome to set up a selfish mining rig and prove me wrong.  Unless you have sufficient hash power to be mining blocks very frequently, no one is even going to notice you exist.

This is an academic exercise with very tiny practical implications, and in any case, a very small threat on the long list of threats.

[eldentyrell]

This is an academic exercise

It isn't even that; arxiv is not peer reviewed.

[dree12]

The minimum difficulty required for a block to be valid is the thing that stays the same.  Within that 2016-block window the actual difficulty of various blocks varies above that threshold.

It would be less ambiguous if you said, "Successful pools do not build on the first block they hear; they build on the block with the highest work they hear."

Well, we're splitting hairs here, but technically I might have gotten lucky and not worked very hard to find a block whose hash, in binary, ends with 250 zeroes in a row (outrageously high difficulty).

But yeah we're talking about the same thing.

This is a statistical fallacy. Two blocks will always be equally difficult when they were mined with the same target.

What you mean to say is that clients prefer to choose the block with the least block hash. This is effectively a deterministic pseudo-random algorithm for choosing which block to build on. I do not remember this being the case, but it is possible this has changed recently.