Bitcoin Forum
May 24, 2017, 03:45:21 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Balance Attack against Bitcoin and Ethereum  (Read 1340 times)
cypherblock
Jr. Member
*
Offline Offline

Activity: 43


View Profile
January 21, 2017, 05:34:51 AM
 #1

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.
POLONIEX TRADING SIGNALS
+50% Profit and more via TELEGRAM
ALTCOINTRADER.CO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1495640721
Hero Member
*
Offline Offline

Posts: 1495640721

View Profile Personal Message (Offline)

Ignore
1495640721
Reply with quote  #2

1495640721
Report to moderator
ranochigo
Legendary
*
Offline Offline

Activity: 1078

Busy due to schoolwork.


View Profile WWW
January 21, 2017, 07:00:36 AM
 #2

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.














 

 

█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
BitBlender 

 













 















 












 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
█ 
piotr_n
Legendary
*
Offline Offline

Activity: 1652


aka tonikt


View Profile WWW
January 21, 2017, 01:31:45 PM
 #3

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.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
cypherblock
Jr. Member
*
Offline Offline

Activity: 43


View Profile
January 21, 2017, 02:09:07 PM
 #4

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
Jr. Member
*
Offline Offline

Activity: 43


View Profile
January 21, 2017, 02:16:44 PM
 #5

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
Legendary
*
Offline Offline

Activity: 1246


ALL escrow is signed! https://keybase.io/verify


View Profile WWW
January 21, 2017, 02:27:11 PM
 #6

-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
Jr. Member
*
Offline Offline

Activity: 43


View Profile
January 22, 2017, 07:12:07 PM
 #7

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
Legendary
*
Offline Offline

Activity: 1652


aka tonikt


View Profile WWW
January 22, 2017, 09:58:32 PM
 #8

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?

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
cypherblock
Jr. Member
*
Offline Offline

Activity: 43


View Profile
January 25, 2017, 01:51:01 PM
 #9

Each of these pools runs tens of nodes...

In separate data centers??
piotr_n
Legendary
*
Offline Offline

Activity: 1652


aka tonikt


View Profile WWW
January 25, 2017, 02:05:55 PM
 #10

Each of these pools runs tens of nodes...

In separate data centers??
What does it matter?

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
cypherblock
Jr. Member
*
Offline Offline

Activity: 43


View Profile
February 02, 2017, 02:21:09 AM
 #11

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.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!