Why SegWit Builds a Network Within a Network
There have been a lot of good things written about Core’s recent release 0.13.1 and the advantages SegWit could provide. A less public feature, however, is that SegWit partitions the network; a 0.13.1 node prefers to connect to other 0.13.1 nodes.
Starting a Bitcoin node means you connect to a network of other nodes. You find your first peers with the help of a public DNS seed, you connect to them, they tell you the addresses of other peers, and you connect to them. After establishing your set of friends, you can download the blockchain from them and help to spread transactions in the network.
Usually, your node is friend with a variety of other nodes; nodes of every country, old nodes, new nodes, nodes running different implementations of the Bitcoin protocol, such as Core nodes, BitcoinJ-nodes, Classic nodes, Unlimited nodes and so on. In an ideal world, the peers of any node represent more than 100 different implementations of Bitcoin which currently populate the network.
The Node that Learned to Differentiate
But those who started a node with the recent release of Core, 0.13.1, which can activate the long-awaited network upgrade SegWit, might experience a surprise; the node changes its connection behavior. It becomes ‘anti-social’ and prefers nodes like itself as good peers. It accepts incoming connections from other nodes, but when searching for new friends, it prefers to accept 0.13.1 nodes for outgoing connections.
This feature can be considered as some kind of blacklisting of other nodes. It seems not only problematic from an ideological perspective that all nodes should be equal, but it risks to partition the network by building a network within a network. Since this is something nobody wants, you would expect that there are serious reasons why the nodes behave like this. And there are.
Partition to Prevent More Partitioning
One point can be found in the release notes on bitcoincore.org. Here Core explains that SegWit as a soft fork faces some risks. A soft fork means that not every node has to upgrade, like in a hard fork, but every miner’s node upgrades are voluntary. This is one of the strongest selling points of SegWit. But it has the risk, as Core explains, that “a poorly handled upgrade could cause the system to fail in additional ways.”
One way to avoid this risk is the building of a network in the network:
“Significant work has gone into ensuring that SegWit enabled peers will form a strongly connected subgraph of the Bitcoin P2P network. This includes providing a dedicated service bit for witness enabled nodes and preferentially connecting to such nodes.”
The exact reason why is not explained. But if we look back, to early 2016, we find a good explanation of Peter Todd in the developer’s mailing list. “SegWit nodes can’t sync from non-SegWit nodes and still be fully validating,” the Core developer writes. The reason is that only SegWit nodes store and verify the signatures of transactions; thus to sync a full SegWit nodes needs to be connected with other SegWit nodes. Todd continues:
“Once the SegWit soft fork has activated full nodes need witness data to function. This poses a major problem during deployment: if full node adoption lags miner adoption, the SegWit-supporting P2P network can partition and lose consensus.”
SegWit as a soft fork comes with the risk, that SegWit nodes have problems finding the data they need to synchronize with the network. To solve this problem, Todd proposes that “peers only connect to peers with SegWit support.” Because of this, he explains, “the SegWit soft-fork has properties not unlike hard-forks in terms of the need for nodes to upgrade with regard to the P2P layer.”
To work properly, SegWit nodes must prefer to be connected to other SegWit nodes. While Peter Todd proposed this as a solution against a partitioning of the network, it seems by itself some kind of partition of the network. At least it makes it more difficult for non-SegWit nodes to connect to the network when the adoption of SegWit increases.
First Downsides are Reported
Right now, only operators of 0.13.1 nodes suffer from this feature. While SegWit is not activated right now, the nodes have already shown a preference to connect nearly exclusively to other 0.13.1 nodes, shown by the images below; this is the result of restarting the node with different setting and shows for the 0.13.1 update, all eight outgoing connections are to other 0.13.1 nodes. One disadvantage is this limited variety of outgoing connections can make it more difficult to connect to mining pools, which can delay the propagation of transactions.
Another disadvantage is that the hard disk workload increases. Several users complained that since they updated to 0.13.1 they note “a sustained higher IO rate for disk reads” and “sudden spikes for IO utilization.” As Core developer, Matt Corallo, explains, “this appears to be other nodes downloading the chain from you, which selected your node due to preferential peering.”
Because of these downsides, one developer proposed to “fix peer selection so that non-Witness peers are still connected to.” His proposal to not activate the strict peer selection until SegWit is activated was rejected by Gregory Maxwell; “NACK. This undoes an intentional design decision. It is not acceptable to have the network topology suddenly change all at one time when SegWit activates.”
At some point of adoption, SegWit might aggressively build up pressure on other nodes to update too.
This article was updated on November 27, 2016.