This study was released last week, detailing some attacks at the network layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of the countermeasures discussed in the paper, the use of encryption to secure communications between nodes looks like low hanging fruit.

See https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki andhttps://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki

On Tue, May 9, 2017 at 12:09 PM, Raystonn . via bitcoin-dev <

Post by Raystonn . via bitcoin-devThis study was released last week, detailing some attacks at the networklayer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Of thecountermeasures discussed in the paper, the use of encryptionto secure communications between nodes looks like low hanging fruit.Raystonn_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Raystonn . via bitcoin-devThis study was released last week, detailing some attacks at thenetwork layer: https://btc-hijack.ethz.ch/files/btc_hijack.pdf. Ofthe countermeasures discussed in the paper, the use of encryptionto secure communications between nodes looks like low hangingfruit.

I draw a very different conclusion.

The paper states:

“Our work underscores the importance of proposed modifications whichargue for encrypting Bitcoin traffic or traffic exchanged among miners.”

The phrase, “encrypting ... traffic exchanged among miners,” is notmerely about encryption, since if one cannot identify the peer as theintended miner it could just as well be an attacker. This is about(presumably encrypted) authenticated connections.

Indeed, encryption of traffic among miners is referred to again here:

“Finally, an attacker cannot intercept (possibly encrypted) privateconnections, corresponding to peering agreements between mining pools.- From the attacker’s point of view, these connections can be treated asintra-pool connections and the corresponding pair of pools can beconsidered as one larger pool.”

So the encryption-based defense for miners is to use authentication tocreate, “one larger pool,” consisting of, “private connections.”

Additionally it states, “we show that hijacking fewer than 100prefixes is enough to isolate a large amount of the mining power dueto Bitcoin’s centralization.”

In other words the proposed solution, to what is largely a problem ofminer centralization, is to create one miner. The paper doesn’tattempt to investigate the downside to that apparent centralizationspiral.

“Yet, we stress that not all routing attacks will be solved by suchmeasures since attackers can still disrupt connectivity and isolatenodes by dropping Bitcoin packets instead of modifying them.”

In other words it recognizes that encryption is both centralizing andineffective. Along these lines it also observes:

* A smaller set of nodes will be easier to isolate for extended periods.* All incoming connection slots can be occupied by connections fromattacker nodes.* Outgoing connections can be biased via a traditional eclipse attack.

Notice that none of these issues are mitigated by encryption, since ineach case the encrypted connection may just as easily be the attacker.The presumed powerful attacker (one with the ability to modifyInternet routing tables) is not deterred by encryption. Instead ofmodifying or dropping packets he can simply redirect traffic to hisown node(s) and carry on the attack on an encrypted connection withthe victim. As such all calls for encryption in the P2P protocolultimately end in calls for authentication.

It is true that if all connections are authenticated these attacks aremitigated. But as the “one larger pool” discussion shows, this issimply a regression to a private network.

As for the two scenarios analyzed, the summary on delay attacks includes:

* Delay attackers intercepting 50% of a node’s connection can waste63% of its mining power.* Due to pools multi-homing, Bitcoin (as a whole) is not vulnerable todelay attackers, even powerful ones.* Even a small degree of multi-homing is enough to protect Bitcoinfrom powerful attackers.

Furthermore, the delay attack scenario explicitly relies on, “the factthat a [Core] Bitcoin node waits for 20 minutes after having requesteda block from a peer before requesting it again from another peer.” Thewaste of mining power above is a function of that delay. So delay isnot a material concern for the entire network, and there aremitigations that hang much lower than making the network private.

* Increase the diversity of node connections* Select Bitcoin peers while taking routing into account* Monitor round-trip time (RTT)* Monitor additional statistics* Embrace churn* Use gateways in different ASes* Prefer peers hosted in the same AS and in /24 prefixes* Use distinct control and data channels* Use UDP heartbeats* Request a block on multiple connections

The single recommendation that includes encryption is heavily qualified:

* Encrypt Bitcoin Communication and/or adopt MAC"While encrypting Bitcoin connections would not prevent adversariesfrom dropping packets, it would prevent them from eavesdroppingconnections and modifying key messages. Alternatively, using a MessageAuthentication Code (MAC) to validate that the content of each messagehas not been changed would make delay attacks much more difficult."

First, it should be widely understood that eavesdropping on the relayof public information is not an attack. Secondly, the paper clearlystates, “attackers can still disrupt connectivity and isolate nodes bydropping Bitcoin packets instead of modifying them.” So thedistinction between dropping and modifying messages is immaterial. Andthirdly, the paper recognizes that eclipse attacks remain effectiveshort of authentication.

Taken alongside the risk of centralization though the widespread useof authentication, which the paper does not contemplate, encryption isanything but low hanging fruit. Several of the other above mitigationsare described as effective, and it is the case that some nodes alreadyemploy some of them. Libbitcoin for example embraces churn byproviding both configurable and partially-randomized connectiontimeout and a configurable block withholding timeout.

The paper is a valuable contribution in assessing risks to the P2Pnetwork and individual nodes, and suggesting mitigations, but it isnot comprehensive. As with block size, the most obvious answer is notalways the right answer. Bitcoin is a public cache of independentlyverifiable information shared anonymously over a P2P network. Theprimary threat is centralization. Authentication is a necessary aspectof centralizing the network.