Hijacking Bitcoin: Routing Attacks on Cryptocurrencies(btc-hijack.ethz.ch)
btc-hijack.ethz.ch
Hijacking Bitcoin: Routing Attacks on Cryptocurrencies
https://btc-hijack.ethz.ch/
7 comments
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.
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.
> 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.
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.
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.
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."
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."
> None of the bitcoin core developers have much experience in network engineering
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.
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.
OP probably meant Core members: https://bitcoincore.org/en/team/
The "team" section of that page doesn't contradict what I said at all.
Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present.
"nor do they recognise the importance of having robust netcode"
Refactoring of the core networking code has been ongoing for quite some time. See https://github.com/bitcoin/bitcoin/projects/4.
"Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present"
sipa? He worked as an SRE at Google before starting work on bitcoin. [1]
rustyrussell? He has done extensive work on the linux kernels networking subsystems. [2]
cdecker? He did a phd at the Distributed Computing Group in Zurich which included work on scaling bitcoin. [3]
gwillen? Also a SRE at Google before bitcoin, and worked on Dapper[1].
[1] https://www.linkedin.com/in/pieterwuille
[2] https://en.wikipedia.org/wiki/Rusty_Russell
[3] https://disco.ethz.ch/alumni/cdecker
[4] https://static.googleusercontent.com/media/research.google.c...
Refactoring of the core networking code has been ongoing for quite some time. See https://github.com/bitcoin/bitcoin/projects/4.
"Can you name anybody with a good background in networking? You can't point to a list of 100 odd names and assert that certain skills must be present"
sipa? He worked as an SRE at Google before starting work on bitcoin. [1]
rustyrussell? He has done extensive work on the linux kernels networking subsystems. [2]
cdecker? He did a phd at the Distributed Computing Group in Zurich which included work on scaling bitcoin. [3]
gwillen? Also a SRE at Google before bitcoin, and worked on Dapper[1].
[1] https://www.linkedin.com/in/pieterwuille
[2] https://en.wikipedia.org/wiki/Rusty_Russell
[3] https://disco.ethz.ch/alumni/cdecker
[4] https://static.googleusercontent.com/media/research.google.c...
Pieter's background is in algorithms and cryptography, he's not a networking engineer. The other people you mentioned are solid but their involvement in development is fairly peripheral, with only a handful of commits between them combined.
It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along.
It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along.
>It doesn't take anything away from my argument that bitcoin's netcode is archaic and remains a major hurdle to scaling, and there is way too much political cruft to move things along.
1. The Bitcoin-devs rewrote the netcode quiet recently moving from a polling model to an event driven model.
2. Look at all the changes in net_processing [0].
3. There has been a long term project to refactor and improve the netcode which has been ongoing for several years and has made massive changes to the netcode. How do I know? Over the last two years I have had to rewrite pull requests several times because the netcode has been rapidly changing.
[0]: https://github.com/bitcoin/bitcoin/commits/master/src/net_pr...
1. The Bitcoin-devs rewrote the netcode quiet recently moving from a polling model to an event driven model.
2. Look at all the changes in net_processing [0].
3. There has been a long term project to refactor and improve the netcode which has been ongoing for several years and has made massive changes to the netcode. How do I know? Over the last two years I have had to rewrite pull requests several times because the netcode has been rapidly changing.
[0]: https://github.com/bitcoin/bitcoin/commits/master/src/net_pr...
>> “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
Direct link to the paper:
https://btc-hijack.ethz.ch/files/btc_hijack.pdf
Level 3, Google, Facebook
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/).
Crypto is misunderstood but can't be ignored. Welcome to the disruption and destruction of the VC model for founders that move things forward.
> "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?
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?
> 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.
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.
> 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.
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.
>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
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
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.
> relying on random numbers being both fair and not being tampered with
You can easily validate that a block is valid and has the correct PoW. For this to work an attacker needs to be mining valid blocks (expensive) and partition the bitcoin network in a way that nodes can't talk to each other (mission impossible). Then the attacker needs to make use of this split chain so that a double spend can occur. I wouldn't be that worried.
You can easily validate that a block is valid and has the correct PoW. For this to work an attacker needs to be mining valid blocks (expensive) and partition the bitcoin network in a way that nodes can't talk to each other (mission impossible). Then the attacker needs to make use of this split chain so that a double spend can occur. I wouldn't be that worried.
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...
This talk is borderline unreadable. Are there slides or something I'm missing?
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)
That would not kill Bitcoin. Nodes will quickly switch to different port, maybe even 80.
Is there any evidence that ISPs want to do this?
(Hint: ISP didn't block BitTorrent because of the MPAA.)
(Hint: ISP didn't block BitTorrent because of the MPAA.)
Comcast blocked BitTorrent in 2008.
https://www.theverge.com/2017/11/22/16691794/net-neutrality-...
https://www.theverge.com/2017/11/22/16691794/net-neutrality-...
No, but I'm sure that given the right financial incentives (hint: third-party) they'd be open to implementing this in practice.
bitcoin over TOR? bitcoin over IRC? bitcoin over websocket (w/ TLS)? bitcoin over facebook messenger?
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.
>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.
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.
Here to all the folks who are A) not legal scholars but pretending to be from their mom's basement and B) unable to reason about the implications but still assert their opinions, there are a ton of references to this issue. Here is one:
https://www.coindesk.com/eroding-net-neutrality-hurt-bitcoin...
https://www.coindesk.com/eroding-net-neutrality-hurt-bitcoin...
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/
I meant legally they can't. They'd be sued and defeated in court. But not if Net Neutrality rules are undone.
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.
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.
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?
If they prioritize traffic to/from one Bitcoin endpoint over another, that falls under net neutrality. If they prioritize non-Bitcoin traffic over all Bitcoin traffic, that doesn't.
Net Neutrality is just about the last mile, not backbone operators. Look it up!
Last mile includes my last mile and your last mile and cannot see why blocking P2P traffic would not be part of the definition of last mile. Each user would be limited to a set of approved centralized services. No user to user routing.
Only user to approved service and approved service to user.
Because net neutrality applies only to how the bits flow over the physical wiring (and radio signals) of the last mile. NOT the backbone. That's what it's about. Backbone operators can and do have peering contracts and give priority to some companies and not others.
ISPs can block all P2P traffic (bits flowing between residential IPs) and removal of Net Neutrality regulations will embolden them to do so, but it's also about the trend toward ISPs being giving the green light to do whatever they want, with eventually no regulation whatsoever.
[0] https://github.com/bitcoin/bips/blob/master/bip-0150.mediawi...
[1] https://github.com/bitcoin/bips/blob/master/bip-0151.mediawi...
[2] https://github.com/bcoin-org/bcoin