What Bitcoin implementations were affected?
Bitcoin Core, Bcoin and Btcd.
Were there any alternative chains affected?
Yes. To our knowledge both Litecoin and Namecoin follow Bitcoin Core code closely and had pulled in the vulnerable code. Decred is based on Btcd which was also vulnerable. Bitcoin Cash was also briefly affected with vulnerable versions of Bitcoin ABC; they had pulled in vulnerable code after it was fixed from Bitcoin Core. We have done our best to check as many implementations as possible.
Am I vulnerable to the attack?
Probably not, the vulnerability has been patched in Bitcoin Core for over two years. However, you are vulnerable to denial-of-service if you're running older software such as:
How can I protect myself?
You are likely already protected. Otherwise, make sure to upgrade:
Who is capable of mounting this attack?
Anyone with an internet and peer-to-peer connection.
How is the attack performed?
A hostile peer floods another peer with many inv messages for non-existent transactions using random hashes.
What is the result of the attack?
A hostile peer can cause another peer to be unable to function, this is known as a denial-of-service. This attack causes the memory of the process to grow endlessly. This will crash the process or freeze the process and computer until the process is terminated.
Could this attack shutdown an entire network?
Yes if 100% of nodes in the network were vulnerable and there were no alternative versions or implementations available that did not have the vulnerability. A fixed version would need to be released to restore the network functionality. For the Bitcoin network there have only been two vulnerabilities (1, 2) that have lead to such downtime events, and there hasn't been one since 2013.
Can this vulnerability be used to steal bitcoin?
Not likely, however it's possible that Lightning Network funds could be at risk if a watchtower or node fails due to a denial-of-service attack. There could then be a failure to counter, within time, a hostile Lightning peer closing a channel.
Can this vulnerability affect consensus?
Not likely, however in some exceptional situations it could influence consensus. The attack could be used to give an advantage to one side of a chain fork or mining hash war. Nodes could be attacked in an attempt to partition the network, in such a case there could be deep chain reorganizations as miners have difficulty propagating blocks across the network. This could cause issues for commerce and trade as block confirmation counts would need to be increased to prevent double-spends.
Is prohibiting inbound connections protection for the attack?
No. An inbound connection is not required for a node to be attacked, only a peer connection. A node's outbound peers can also initiate the attack. The attacker could have an otherwise normal operating full node or network of nodes that peers could connect. The attacker could Sybil attack the network and announce with addr messages many IP addresses to gain more connections.
Is running a non-public internal node protection for the attack?
No. The attack is not prevented by running a node that is isolated from the public internet and only connecting to edge nodes that have connection to the public network. The nodes that are on the public internet, edge nodes, can be attacked and the internal node would lose connection to the network and would not receive or send new blocks or transactions.
Has this been exploited in the wild?
Not as far as we know.
Who is behind this research?
Braydon Fuller (Github) and Javed Khan (Github, Twitter).