Balance Attack against Bitcoin and Ethereum

[cypherblock]

Any thoughts on this paper https://arxiv.org/pdf/1612.09426.pdf ?

It describes a "Balance Attack" against bitcoin and ethereum where you split the miners into 2 equal groups by causing a communications delay between them. Then you mine with one group while submitting transactions (for merchandise, services, etc) to nodes connected only to the other group (and you can send same coins to yourself on your mining branch). When the communications delay is lifted the chain being worked on by the group you were mining with should be longer than the other group's chain, so consensus will then cause your spent merchandise transactions to get undone, while spends to yourself from your mined chain will persist. Thus a double-spend.

Authors were focused on Ethereum and private R3 implementation but they also think their work extends to Bitcoin as well.

Why do miners have to be evenly split to start with?  Also, they use "communications delay" but for bitcoin, this would be more of a disruption between the 2 groups right? Also the need to isolate the node you are purchasing goods from to one side.

So definitely a few challenges pulling it off. Still with small number of mining pools controlling most of hash rate, it doesn't seem crazy that they could be split into 2 groups.

[1714834069]

1714834069

[ranochigo]

Why do miners have to be evenly split to start with?

I doubt it would work with a great certainty if you were to disconnect two portions of miners and both of them have the same hashrate. Bitcoin Core will only accept the chain with the longest valid blocks and you need to ensure that you are spending to the merchant on the correct chain.

Also, they use "communications delay" but for bitcoin, this would be more of a disruption between the 2 groups right?

If the two groups do not know the blocks that each other is mining, one of the chain will eventually be orphaned.

For example, if group A mines Block 1, Group B would, in a perfect scenario mine Block 2. However, since they do not know the block has already been mined, they will mine their own Block 1 and thus have a competing blockchain against Group A. If Group A were to have a higher hashrate, there is a higher chance of the chain being accepted by the network.

Also the need to isolate the node you are purchasing goods from to one side.

Yes. You need to know which fork the merchant is on. See this example: https://bitcointalk.org/index.php?topic=152348.0.

[piotr_n]

I find it quite impossible in practice, to "split the miners into 2 equal groups by causing a communications delay between them".
It's probably even harder than splitting the internet in half.

[cypherblock]

I doubt it would work with a great certainty...

I think the point is that it would work with great certainty if you are able to achieve the requirements (insert long delay/disruption between 2 groups of miners and isolate a merchant node to one side). In fact given a long enough time period the certainty approaches 100%.

If the two groups do not know the blocks that each other is mining, one of the chain will eventually be orphaned.

Yeah that is the entire point, of the attack.

Anyway, my questions surrounding this attack are:

* Why does the paper call for making an even split between 2 groups of miners, as it's starting point? Wouldn't any division 10%/90% work just as well if you were able to isolate a merchant to the 10%?
* Does this paper highlight anything new? (it seems obvious that comm disruption between groups will cause chain separation and removing disruption will cause one chain to get orphaned).
* For blockchains like Ethereum with short times between blocks I guess the term "delay" is appropriate, but really we are causing a complete comm disruption, for the time under which the attack takes place, between the groups, no?

[cypherblock]

I find it quite impossible in practice, to "split the miners into 2 equal groups by causing a communications delay between them".
It's probably even harder than splitting the internet in half.

If you look at this hashrate chart, you can see that by just targeting the 4 largest pools you could split the hashrate into 2 equal groups. So much easier than splitting internet in half. Now still there is the requirement of isolating a merchant node, so that it is only seeing blocks from one side. But problem seems halfway solved with 4 pool attack.

[shorena]

-snip-
Yeah that is the entire point, of the attack.

Anyway, my questions surrounding this attack are:

* Why does the paper call for making an even split between 2 groups of miners, as it's starting point? Wouldn't any division 10%/90% work just as well if you were able to isolate a merchant to the 10%?

Because a 50% split is enough. The idea is that you join the 50% side to make it stronger. Any bigger split would only improve your chances to pull this off.

* Does this paper highlight anything new? (it seems obvious that comm disruption between groups will cause chain separation and removing disruption will cause one chain to get orphaned).

I have not read it, but it does not sound like anything new. To me this sounds like a sybil attack on miners.

* For blockchains like Ethereum with short times between blocks I guess the term "delay" is appropriate, but really we are causing a complete comm disruption, for the time under which the attack takes place, between the groups, no?

No thats not needed and might cause the attack to get revealed. The delay must just be long enough for the victim to notice the confirmation(s), the attacker taking advantage of that fact and the block(s) getting orphaned.

I find it quite impossible in practice, to "split the miners into 2 equal groups by causing a communications delay between them".
It's probably even harder than splitting the internet in half.

If you look at this hashrate chart, you can see that by just targeting the 4 largest pools you could split the hashrate into 2 equal groups. So much easier than splitting internet in half. Now still there is the requirement of isolating a merchant node, so that it is only seeing blocks from one side. But problem seems halfway solved with 4 pool attack.

Still sounds like a difficult attack as you would need in depth knowledge how the miners are contected to the network and how those providing the actual hashing power are connected to the central node. There might also be fail saves in place.

Even if you just kick them of the relay network and there is no fail save (which I doubt considering the potential losses) you need to make sure no one gets a "something is wrong"-mail and notices the attack.

[cypherblock]

I have not read it...

Hmm, was sort of hoping some other folks would take a look. That is why I started the thread, wanted to see if I was missing or misinterpreting something. If you are just going off of my summary, regurgitation, then something could be missed. Please review the source material if you can.

The delay must just be long enough for the victim to notice the confirmation(s)

Well for bitcoin, this would might mean at least a 20 minute delay for 1 confirmation. "20 minute" because if you are splitting the hash rate pretty evenly then sending your merchandise transactions to one side, then on average it would take 20 minutes for 1/2 the hash rate to mine one block. So that is a 20 minute "delay". I would call it a 20 minute disruption. But let's not get caught on semantics unless I'm misunderstanding something.

... how those providing the actual hashing power are connected to the central node. There might also be fail saves in place.

Someone familiar with mining pools should be able to answer this. If indeed remote miners (outside of the pool's network) are contributing to a pool, who announces the found block to the bitcoin network? It is the mining pool isn't it? I don't think the individual miners even know what transactions are included, they are using the block header only. So centralized mining pool is what announces the found block. Correct?

Yes the attack still may be difficult. We must take 4 mining pools, allow them to connect to each other's nodes (or get blocks over relay network), but prevent them from reaching other nodes (or getting relay network blocks) that are connected to the other side. Because mining pools are centralized in one geographic area (China) this would seem to make the task somewhat more feasible. Still a challenge no doubt.

[piotr_n]

If you look at this hashrate chart, you can see that by just targeting the 4 largest pools you could split the hashrate into 2 equal groups.

"Targeting" how?

Each of these pools runs tens of nodes and each of these nodes connects to tens of peers, from all over the world.
How do you imagine delaying information about new blocks coming to these nodes?

[cypherblock]

Each of these pools runs tens of nodes...

In separate data centers??

[piotr_n]

Each of these pools runs tens of nodes...

In separate data centers??

What does it matter?

[cypherblock]

Each of these pools runs tens of nodes...

In separate data centers??

What does it matter?

If everything is in one data center then there may only be one entry/exit point for all data. If someone were to infiltrate the main router or other network appliance there, then they can remove packets inbound from certain IP addresses and block outgoing packets to some IP addresses. Hence communication disruption. So it is just easier when there is one data center and fewer things to infect/control.

Think like Stuxnet or something.