Network Partitioning

Bitcoin Core recently merged in a pull request from Matt Corallo which disconnects certain nodes. This has caused some interesting takes by several prominent people. In this post, I’m going to describe what this pull request does.

The Bitcoin Network

Before I start explaining this pull request, we first need a little background on how Bitcoin’s network actually operates.

Bitcoin’s network operates in a peer-to-peer fashion. That is, every computer running Bitcoin software connects to other computers that are running Bitcoin software. There’s no central place that all these computers connect to. Instead, they connect to each other.

New transactions and blocks are transmitted on this network and each computer sends this information to other computers as they see them. The network is designed this way so that no single computer, or even a group of computers, can shut down the network. Indeed, this is one of the Bitcoin network’s strengths.

Connecting To Other Computers

When a new computer joins the network, it has to figure out which other computers to connect to. This is generally done by finding at least one other computer that’s on the network, asking that computer what other computers it’s connected to and connecting to those and asking those computers what other computers they’re connected to and connecting to those and so on.

The process of connecting to another computer is what’s called a handshake. During a handshake, the computers send information about the software that they’re running. This is what the code change is about.

Services

During a handshake, computers announce two things; first, the network identifier (“network magic” in tech speak) and second, the services that they have.

The network identifier is normally used to make sure the computer is connected to another computer on the same network. Each cryptocurrency generally has a unique network identifier. This is how Litecoin software makes sure it’s connecting to other computers running Litecoin software and not Monero.

Unfortunately with Bitcoin ABC and Segwit2x, they use the same network identifier (most likely because both hope to replace Bitcoin).

Both differentiate themselves from Bitcoin Core by announcing their software as a service that they have. Bitcoin ABC started using bit 5 to announce that computer is running Bitcoin Cash. Segwit2x’s software, btc1, is using bit 7 to announce that the computer is running Segwit2x.

The Pull Request changes Bitcoin Core 0.15 so that any computer announcing service at bits 5 or 7 (6 or 8 according to the PR since Matt’s counting is 1-based) are disconnected automatically. That is, computers running Bitcoin ABC or btc1 are disconnected from computers running Bitcoin Core 0.15.

The effect of this is that computers running Bitcoin Core are in one group and computers running Bitcoin ABC/btc1 are in another. This is what we call network partitioning. That is, there are essentially two networks instead of one.

Bitcoin Cash/Bitcoin ABC

We know, because of wipeout and replay protection built into Bitcoin Cash, that blocks and transactions from Bitcoin Cash are not valid on Bitcoin and vice-versa.

Thus, it makes sense to disconnect these computers since validating blocks and transactions that we know to be invalid would be a waste of the computer’s time. Furthermore, it’s in the best interest of both Bitcoin and Bitcoin Cash to not mix. Bitcoin’s network doesn’t care about what’s happening on Bitcoin Cash’s network and vice-versa.

For this reason, disconnecting computers that are running Bitcoin ABC (Bitcoin Cash’s client) and partitioning the network makes all the sense in the world.

Note that even without this change, when a Bitcoin Cash computer is connected to a Bitcoin computer, receiving an invalid block or transaction causes them to disconnect each other, so preemptively disconnecting is just being more efficient.

Segwit2x/btc1

Segwit2x’s situation is a bit trickier. In some cases, partitioning the network can be good, and in others, not partitioning the network is good.

We know there’s a plan for a hard fork to 2x the blocksize limit in November. This may mean two coins, Bitcoin Core coin and Segwit2x coin.

Supposing we only have one coin, partitioning the network would be marginally bad. I say marginally since there still would most likely be a single ledger, but the blocks and transactions wouldn’t propagate as fast. This also increases slightly the possibility of a block reorganization.

Supposing there are two coins, partitioning the network would be very good. Because Segwit2x has wipeout protection, blocks from btc1 will not be valid on Bitcoin and vice-versa. This means that the computers would be disconnecting each other once they see the blocks.

We want to partition sooner if we’re anticipating a partition since doing so suddenly when a fork happens may isolate the computer without anyone to connect to. As a computer, you won’t have to suddenly disconnect from other computers and be left isolated from the network you want to be on. This is a win-win for both network partitions since you want computers that are running the correct software on the network.

Given this situation, the Core developers felt that the marginal loss of the former scenario was not enough to outweigh the major gain of the latter scenario and merged this pull request.

Conclusion

So what does this mean? Bitcoin Core 0.15 will make the network a little safer. A little bit, because unless other implementations follow suit and every computer upgrade, a network that really should be partitioned will still be connected.

Should Segwit2x cause a network split, Bitcoin Core will help partition the network in a useful way.

Want to get curated Technical Bitcoin News? Sign up for the Bitcoin Tech Talk newsletter!