
Hijacking Bitcoin: Routing Attacks on Cryptocurrencies - federicoponzi
https://btc-hijack.ethz.ch/
======
nikcub
BIP150[0] adds peer authentication, BIP151 adds encrypted peer communication.
Having them implemented and enforced is probably overdue - afaik so far i've
only seen bcoin[2] implement it

[0]
[https://github.com/bitcoin/bips/blob/master/bip-0150.mediawi...](https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki)

[1]
[https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...](https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki)

[2] [https://github.com/bcoin-org/bcoin](https://github.com/bcoin-org/bcoin)

~~~
Laforet
None of the bitcoin core developers have much experience in network
engineering nor do they recognise the importance of having robust netcode. It
is no susprise that they see no urgency to address the vulns.

Morever, their obsession with phasing in every change via a soft fork (i.e.
updated nodes must be eternally backwards compatible with older versions) puts
an unreasonable constraint on protocol development and snuffs any progress
that is ever so slightly controversial.

~~~
VMG
> Morever, their obsession with phasing in every change via a soft fork (i.e.
> updated nodes must be eternally backwards compatible with older versions)

This "obsession" is about the consensus layer, for very good reasons.

The peer-to-peer protocol is much more flexible, and a lot of work is being
done there.

~~~
Laforet
Adding authentication needs to break compatibility with older versions to be
safe, or else an attacker could simply masquerade as an older client and
perform an effective downgrade attack. As in what's happening with DNSSEC
implementations.

~~~
EthanHeilman
When talking about breaking compatibility in Bitcoin you should recognize two
district classes of compatibility.

1\. Consensus compatibility i.e. that a node running the new software and a
node running the old software will, when given the same blockchain, will
always agree on which blocks are valid and which blocks are invalid.

2\. Everything else.

Breaking consensus compatibility is viewed as very risky and should only
happen under extreme circumstances or under extreme agreement. Breaking
backwards compatibility at the network level should be carefully thought
through but it is much more likely to happen.

>an attacker could simply masquerade as an older client and perform an
effective downgrade attack

BIP-151 is only designed to defeat a passive attacker since it does not
include a way of attaching a long term identity to a node. Thus, even without
a downgrade attack you can just MITM a connection and substitute your own
keys. As BIP-151 says:

"The encryption does not include an identity authentication scheme. This BIP
does not cover a proposal to avoid MITM attacks during the encryption
initialization."

BIP-150 is the identity mechanism for BIP-151 however establishing the pubkey
to node mapping requires out of band communication.

"The identity-public-key(s) can be shared over a different channel with other
node-operators (or non-validating clients) to grant authorized access."

------
wonderous
>> “Moreover, most of the traffic exchanged between Bitcoin nodes traverse few
ISPs. Indeed, our results indicate that 60% of all possible Bitcoin
connections cross 3 ISPs. In other words, 3 ISPs can see 60% of all Bitcoin
traffic.”

Direct link to the paper:

[https://btc-hijack.ethz.ch/files/btc_hijack.pdf](https://btc-
hijack.ethz.ch/files/btc_hijack.pdf)

~~~
albeebe1
Level 3, Google, Facebook

------
tlrobinson
If you’re concerned about this type of attack it’s pretty easy to defend
against. All it takes to avoid partition is a single connection across a VPN,
Tor, or even satellite
([https://blockstream.com/satellite/](https://blockstream.com/satellite/)).

------
KasianFranks
Crypto is misunderstood but can't be ignored. Welcome to the disruption and
destruction of the VC model for founders that move things forward.

------
albertgoeswoof
> "An attacker can use routing attacks to partition the network into two (or
> more) disjoint components. By preventing nodes within a component to
> communicate with nodes outside of it, the attacker forces the creation of
> parallel blockchains. After the attack stops, all blocks mined within the
> smaller component will be discarded together with all included transactions
> and the miners revenue. "

How does bitcoin protect against this from happening by accident? Could
someone surround my node with malicious nodes and put me on a forked chain?

~~~
runeks
> Could someone surround my node with malicious nodes and put me on a forked
> chain?

Yes. You can’t know about blocks you don’t hear about. However:

1\. Unless they can match the hashing power of the rest of the network, they
can only publish new blocks to you at a very low rate (e.g. every 100 minutes
if they have 10% of the hashing power)

2\. If you connect to just a single node which tells the truth, you will
discard the forked chain (again, unless the attackers can match the hash rate
of the rest of the network)

All in all, proof-of-work makes it pretty easy for you to notice that
something weird is happening.

> How does bitcoin protect against this from happening by accident?

You can prevent nodes from connecting to you (no inbound connections), such
that _you_ choose (randomly) which nodes to connect to. Choose a sufficiently
high node count, and you’re almost certain that you don’t select a group of
coordinating malicious nodes.

 _Side note:_ It would also be interesting to analyze the impact of this
attack in the context of a proof-of-stake blockchain. I assume, although I’m
not certain, that the attacked node would just consider the current stakers as
defunct if the attackers don’t deliver blocks from them, and that the
attackers would be able to become the new stakers, since the attackers would
be able to censor competing staking transactions.

~~~
ben_w
> You can prevent nodes from connecting to you (no inbound connections), such
> that you choose (randomly) which nodes to connect to. Choose a sufficiently
> high node count, and you’re almost certain that you don’t select a group of
> coordinating malicious nodes.

This sounds suspiciously like either a) choosing who to trust in advance,
which negates one of the few benefits of blockchain-based cryptocurrencies
that I accept exist (even if I don’t value it highly); or b) relying on random
numbers being both fair and not being tampered with, even though over-reliance
on that is one of the common failure modes with cryptography in general.

~~~
EthanHeilman
>b) relying on random numbers being both fair and not being tampered with,
even though over-reliance on that is one of the common failure modes with
cryptography in general.

If you are interested I was an author on a paper which looked at the
probability of choosing bad nodes, how an attacker could manipulate this and
what bad things an attacker can do once they partition you from the network.
Many of the countermeasures and security enhancements we proposed are now in
Bitcoin making the network harder to attack.

> Could someone surround my node with malicious nodes and put me on a forked
> chain?

Eclipse Attacks on Bitcoin’s Peer-to-Peer Network
[https://eprint.iacr.org/2015/263.pdf](https://eprint.iacr.org/2015/263.pdf)

~~~
albertgoeswoof
Thanks for this paper, it’s a really excellent read and explains the eclipse
attack really well. I would love to track down some similarly structured
papers.

------
kanzure
One of the authors gave a talk earlier this month at Stanford on lightning
network and fees,
[http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-20...](http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/how-
to-charge-lightning/)

~~~
Buttes
This talk is borderline unreadable. Are there slides or something I'm missing?

~~~
kanzure
[https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m](https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m)

------
idibidiart
Also like I said removal of net neutrality regulations means ISPs esp big ones
can kill Bitcoin by blocking the default port used by the Bitcoin client and
ISPs can more than just blocking a certain port. ISPs can identify and block
all P2P traffic (anything that is not being sent or received to/from an
approved central service) and do it in the name of protecting MPAA member
revenue or whatever blanket execuse like killing off encrypted p2p
communication like Signal et al)

~~~
wmf
Is there any evidence that ISPs want to do this?

(Hint: ISP didn't block BitTorrent because of the MPAA.)

~~~
TehCorwiz
No, but I'm sure that given the right financial incentives (hint: third-party)
they'd be open to implementing this in practice.

~~~
gruez
bitcoin over TOR? bitcoin over IRC? bitcoin over websocket (w/ TLS)? bitcoin
over facebook messenger?

~~~
TehCorwiz
Sure, but closing the _default_ port limits the tech to people with the
interest and technical knowledge to proxy it in such a way. ISPs could also do
DPI or timing analysis to id the stream and slow or block it. It was tried
successfully (by Comcast) on bittorrent in the the early 00's and is one of
the things that triggered the whole Title II fight in the first place.

~~~
gruez
>It was tried successfully (by Comcast) on bittorrent in the the early 00's
and is one of the things that triggered the whole Title II fight in the first
place.

torrents are hard to hide because no matter how much encryption/obfuscation
you do, you can't hide gigabytes of data being transferred between residential
IPs, using random ports. bitcoin uses megabytes of data _per hour_ , which
means it's much easier to use stenography to hide it.

