Search on TFTC
Issue #554: Highlighting an interesting attack vector

Issue #554: Highlighting an interesting attack vector

Aug 22, 2019
Marty's Ƀent

Issue #554: Highlighting an interesting attack vector

Here's an interesting attack vector that has been brought to light by researchers from Singapore, Korea, and Japan in recent weeks; the Erebus attack. This particular attack allows nefarious Internet Service Providers to partition individual nodes from the rest of the network and begin feeding them bad information to enable double spends or attempt to 51% attack the network. Not ideal for a system dependent on a secure, robust peer-to-peer messaging network.

The way I understand it, a large ISP can trivially target Bitcoin nodes operating on their networks and begin a slow, yet invisible attack that aims to force targeted nodes to reboot and reestablish outgoing connections with the attacker's malicious nodes. Working silently in the background over the course of weeks to achieve this goal. According to the researchers, the probability of this attack being successful after 45 days is < 30%.

This certainly seems like something that would be pretty easy for a motivated actor in the right position to attempt. Whether that be an ISP headed by an evil mastermind, or, the more likely culprit IMO, a State actor demanding access to an ISP's systems so they can execute the attack. Regardless of who initiates the attack, this is something that one should be very aware of if they truly care about Bitcoin's long term survival. The need for alternative transaction relay networks enabled by mesh and satellite networks should be very apparent in the face of attacks like this. A prime, niche example or why one should always be thinking adversarially when it comes to Bitcoin.

Fear not though, there are very smart individuals out there thinking very adversarially, helping to identify this vulnerability so we can fix it. Bitcoin contributors working on the peer-to-peer layer are already hard at work devising solutions. One of which involves making sure nodes diversify their ISP and cloud hosting risk by only connecting to a limited number of nodes from each provider. Using IP addresses to help identify and isolate individual entities. Another solution involves upping the number of outgoing connections nodes can have with other nodes to decrease the chances of a malicious actor fully partitioning a node from the rest of the network.

The good part about changes at the peer-to-peer layer of the network is that they are not consensus rule changes so we do not need to have a long-drawn-out battle about how to merge this in. We can all sleep easy now, but let this be a reminder to never get complacent. Complacency kills.

Final thought...

Would be awesome if I could get these bad boys out the digital door by 9am every day. Need to up my game.


Current Block Height

Current Mempool Size

Current Difficulty