11 ms·

Hijacking Bitcoin: Routing Attacks on Cryptocurrencies

141 points by federicoponzi 9y ago

wonderous 9y ago
>> “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 9y ago
  Level 3, Google, Facebook
kanzure 9y ago
One of the authors gave a talk earlier this month at Stanford on lightning network and fees, http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-2017/how-to-charge-lightning/ http://diyhpl.us/wiki/transcripts/scalingbitcoin/stanford-20...
- Buttes 9y ago
  This talk is borderline unreadable. Are there slides or something I'm missing?
  - kanzure 9y ago
    https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m
idibidiart 9y ago
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)
- EGreg 9y ago
  To be fair, can't backbone providers already do this? https://www.wired.com/2014/06/net_neutrality_missing/ https://www.wired.com/2014/06/net_neutrality_missing/
  - idibidiart 9y ago
    I meant legally they can't. They'd be sued and defeated in court. But not if Net Neutrality rules are undone.
    - curun1r 9y ago
      Net neutrality rules are about source/destination of traffic, not the type. ISPs are allowed to discriminate for/against traffic based on the type of traffic and it would be terrible to prevent them from implementing those kinds of QoS rules. If we're going to defend net neutrality, we should at least understand what we're fighting for. And it's decidedly not to allow BitTorrent traffic to make real-time protocols like VOIP unreliable. It's about not letting ISPs favor one service over its competitors. And it's about making sure that an indie developer can send traffic to internet users just as fast as Google can. Discussions on technically-informed sites like this one should get the details of net neutrality correct.
      - pas 9y ago
        Everything is (or slowly will be) TLS of UDP port 443. Now what type?
        tscs37 9y ago
        Deep Packet Inspection. Just run it all over HTTPS.
      - idibidiart 9y ago
        Going with your "source/destination" definition, one Bitcoin/Signal user is source and the other is destination. They can require traffic to be exclusively between user and approved service provider, can't they?
tlrobinson 9y ago
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/).
nikcub 9y ago
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.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0150.mediawi... [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi... [2] https://github.com/bcoin-org/bcoin https://github.com/bcoin-org/bcoin
- Laforet 9y ago
  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.
  - mitchellberry 9y ago
    > None of the bitcoin core developers have much experience in network engineering https://github.com/bitcoin/bitcoin/graphs/contributors https://github.com/bitcoin/bitcoin/graphs/contributors Many are anonymous or use psuedonoyms. Cohort easily over 100. Seems like an incredibly bold assertion to make about such a large group of developers.
    - pas 9y ago
      OP probably meant Core members: https://bitcoincore.org/en/team/ https://bitcoincore.org/en/team/
      - mitchellberry 9y ago
        The "team" section of that page doesn't contradict what I said at all.
KasianFranks 9y ago
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 9y ago
> "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 9y ago
  > 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 9y ago
    > 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.

141 points by federicoponzi 9y ago

>> “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 9y ago
Level 3, Google, Facebook

kanzure 9y ago

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

Buttes 9y ago
This talk is borderline unreadable. Are there slides or something I'm missing?
- kanzure 9y ago
  https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m https://www.youtube.com/watch?v=3pd6xHjLbhs&t=1h3m

idibidiart 9y ago

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)

EGreg 9y ago
To be fair, can't backbone providers already do this? https://www.wired.com/2014/06/net_neutrality_missing/ https://www.wired.com/2014/06/net_neutrality_missing/
- idibidiart 9y ago
  I meant legally they can't. They'd be sued and defeated in court. But not if Net Neutrality rules are undone.
  - curun1r 9y ago
    Net neutrality rules are about source/destination of traffic, not the type. ISPs are allowed to discriminate for/against traffic based on the type of traffic and it would be terrible to prevent them from implementing those kinds of QoS rules. If we're going to defend net neutrality, we should at least understand what we're fighting for. And it's decidedly not to allow BitTorrent traffic to make real-time protocols like VOIP unreliable. It's about not letting ISPs favor one service over its competitors. And it's about making sure that an indie developer can send traffic to internet users just as fast as Google can. Discussions on technically-informed sites like this one should get the details of net neutrality correct.
    - pas 9y ago
      Everything is (or slowly will be) TLS of UDP port 443. Now what type?
      - tscs37 9y ago
        Deep Packet Inspection. Just run it all over HTTPS.
    - idibidiart 9y ago
      Going with your "source/destination" definition, one Bitcoin/Signal user is source and the other is destination. They can require traffic to be exclusively between user and approved service provider, can't they?

tlrobinson 9y ago

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/).

nikcub 9y ago

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.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0150.mediawi... [1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi... [2] https://github.com/bcoin-org/bcoin https://github.com/bcoin-org/bcoin

Laforet 9y ago
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.
- mitchellberry 9y ago
  > None of the bitcoin core developers have much experience in network engineering https://github.com/bitcoin/bitcoin/graphs/contributors https://github.com/bitcoin/bitcoin/graphs/contributors Many are anonymous or use psuedonoyms. Cohort easily over 100. Seems like an incredibly bold assertion to make about such a large group of developers.
  - pas 9y ago
    OP probably meant Core members: https://bitcoincore.org/en/team/ https://bitcoincore.org/en/team/
    - mitchellberry 9y ago
      The "team" section of that page doesn't contradict what I said at all.

KasianFranks 9y ago

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 9y ago

> "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 9y ago
> 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 9y ago
  > 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.