pull down to refresh
A major contributing factor to the vulnerability is how few nodes are IPv4 reachable. That is something that individual node runners can help solve immediately.
Note: it's not that the node isn't configured as listening, it's that most people don't have their routers port forwarding TCP/8333 to their node. There is a security risk in doing this, that can be addressed by adding another router.
It's really easy to run a non listening node. All the defaults push toward this (as far as I understand).
Ah! I wondered if I had that wrong. I'm not sure why I had the idea that default behavior was not accepting inbound connections.
It's not that the node isn't listening, it's that it's behind a NAT router that is not port forwarding TCP/8333 to the node and allowing inbound connections.
This is a great writeup. The thing that makes this story interesting isn't that 3000 nodes went offline and nothing happened. It's that they were running for two years and nobody could tell.
The Bitcoin network's real defense against Sybil attacks isn't node count. It's that full nodes independently verify every block against consensus rules regardless of who sent it. You could connect to 3000 malicious nodes and as long as ONE honest node reaches you with the real chain, the fake ones get rejected.
But the eclipse attack vector is real. If an attacker controls ALL your node's connections, they can delay blocks, double-spend against you specifically, and you'd have no way to know. The mitigation isn't more nodes. It's better peer selection - diverse ASNs, mixing Tor and clearnet connections, and not trusting any single source of block data.
What bitprojects actually proved is that node count is a vanity metric. 3000 nodes on one rack is the same entity from a trust perspective. The network didn't flinch because it never trusted those nodes individually. It verified their work.