Taking a step back from analyzing individual defenses, it’s important to understand the actual Bitcoin network itself.
After all, as we saw with publish or perish, which sounded really awesome in theory, it ultimately fails to work in practice due to assumptions about certain properties about the Bitcoin network — particularly that of synchrony.
So first off, the Bitcoin network is peer to peer, and there’s no central entity sending and receiving messages for us.
The way that messages get sent around the network is through a gossip protocol, which also called flooding.
Basically if i want to send out a transaction i have to tell all the nodes i’m connected to, which we call my neighbors.
All my neighbors tell their neighbors, and their neighbors tell their neighbors, and so on.
For example, if the network actually looked like this… …and I wanted to send a message to Nick… …I would tell my neighbors Derrick and Gloria.
Derrick and Gloria would then tell their neighbors, and thankfully Derrick is connected to Nick, so Nick gets my message.
Also, one note is that as we discussed in the Bitcoin mechanics module, my message would be digitally signed.
The way you get connected and join the Bitcoin network in the first place is by a recursive procedure.
Hardcoded into the Bitcoin core software is a list of seed peers that you connect to initially.
You ask these seed nodes for their neighbors, pick some, ask these nodes for their neighbors, and repeat this until you think you have a fairly random set of connections.
Bitcoin allows each node to have a maximum of 125 connections, and generally you have 8 outbound connections and 117 inbound connections.
To further understand how information propagates through the Bitcoin network, we have to understand the network topology and latency.
Network topology means how the Bitcoin network looks like if you were to graph it out like we’ve been doing with circles — for individual nodes — and lines — for connections between nodes.
In Bitcoin, we want an even topology.
We want each node to have roughly the same weight, mining power in our case, have random connections, and look fairly uniform.
But this isn’t really the case.
As we know, there’s a huge difference in mining power node to node.
This means that some nodes are more influential than others.
So is the Bitcoin network truly as decentralized and distributed as we thought? Nope.
Let’s say Derrick has an incredibly high hash rate… It could be that he’s running a mining farm or pool.
We can’t really tell, since mining farms and pools sometimes want to remain secret so people don’t attack them.
Derrick is arguably more influential than other nodes in the network.
Compare his hash power with someone who’s just an SPV node hanging out in the network, or a node that’s just a solo miner.
Derrick’s pool a lot more hash power than any of these.
And there’s no easy way of determining the network topology.
If Derrick is running a mining pool, his miners don’t have to be directly connected on the Bitcoin network at all.
They could just be connecting to Derrick’s node directly through some lightweight protocol.
So all of Derrick’s miners form a secret subgraph essentially.
And it turns out that due to this hidden graph topology, and the fact that Derrick could be multiple nodes on the network, possibly running multiple pools, Derrick could potentially hide the fact that he has more than 50% of the network hash power.
And scarier yet, Derrick doesn’t even need 50% of the network hash power.
As we saw with the attacks and defenses previously, Bitcoin suffers from some incentive alignment problems, especially in the case of selfish mining.
As it turns out, the Bitcoin network could be in jeopardy if Derrick’s pool — or pools — had 33% of the network hash rate.
Or 25%… or 23.2%….or 32%….
Perhaps there’s an attack or selfish mining scheme that hasn’t been discovered yet that lowers the profit threshold even lower.
In addition to network topology, we also have to worry about the network latency.
As we saw in publish or perish, a selfish miner could publish his secret blocks right before it’s too late.
Some nodes would see it as in time, and others would see it as late.
And that’s a pretty good example for how network latency is an issue here.
Also, consider the case where two miners find a valid block at the same time.
There’s a race to propagate like before, and the miner who is better connected in the network and has a faster propagation time would ultimately win.
This leads to disproportionate profits in miners.
Miners who are better connected in the network see things faster and are able to send out messages and blocks faster too.
Meanwhile, it’s possible that a poorly connected miner could spend all this time finding a block, and when it finally finds one, its propagation time could be so slow due to network latency that within that time, another miner would have already found and submitted a competing block to a majority of the network.
And now for something even bigger.
Think back to the first module, where we discussed Sybil attacks and how it’s not beneficial to have more identities because in Proof-of-Work, we make computational power the limiting factor.
Well, if we’re clever enough, we can launch a Sybil attack in another kind of way, leveraging what we just went over: network topology and latency.
Let’s say Derrick has the ability to flood the network with nodes.
These could either be his miners, or if he’s clever enough, he could even write malware that make victims’ computers act like 0-power nodes — just sitting there listening to the Bitcoin network, and relaying information back to Derrick.
They’d act like sensors.
Derrick could sybil attack honest miners by leveraging his network level dominance.
Let’s say Derrick is also selfish mining, and already has some secret blocks, which are distributed to all of his 0-power nodes.
When Derricks nodes hear about the next honest block X, Derrick could ignore X, and publish his secret block P.
If block P reaches a miner before block X, then the miner by default mines on block P.
So in this attack, Derrick leverages both the network latency and topology.
Derrick is well connected and has less latency, and is able to propagate his secret block P faster than if he only had control of one node.
He also also his unique ownership of the network topology, since he owns a lot of nodes around the network, and also since he has a large proportion of the network mining power.
So, as a closing note, know that outside of what we presented in this module, there are a lot more attacks and defenses, such as eclipse attacks and stubborn mining, which take into account network latency, topology, and more.