Bitcoin Mempool: Relay Network Dynamics

In the final Mempool article, we discussed the different types of relay policy filters, why they exist, and ultimately the incentives that determine how effective each class of filters are to prevent confirmation of transactions of different classes. In this article, we will examine the dynamics of a relay network if some nodes on the network are running different relay policies compared to other nodes.

If a node on the network runs a homogenous relay policy with Mempool, all transactions must propagate throughout the network, given that they pay the minimum salary that should not be ousted from the node’s memory during a large transaction backlog. This is changed if different nodes on the network are running heterogeneous policies.

The Bitcoin Relay Network works on a best effort basis using what is called a flood filling architecture. This means that when a transaction is received on one node, it is forwarded to all other nodes except for the node that received the transaction. This is a highly inefficient network architecture, but in the context of a distributed system, it provides a high degree of assurance that transactions will ultimately reach the intended destination, the miner.

Introducing filters in a node’s relay policy to theoretically limit relays of other valid transactions will introduce friction in the propagation of that transaction, reducing the reliability of the network’s ability to perform this function. In reality, things aren’t that simple.

The amount of friction prevents propagation

Let’s take a look at a simplified example of various network node configurations. The next graphics blue node represents it Intention Consensus propagates any class of valid transactions, and the red node is do not have Propagate these transactions. The set of miners is centrally shown as a simple expression of where the transaction user ultimately wants to ultimately engulf the transaction.

This is a model for networks where nodes that reject the propagation of these transactions are clearly minority. As you can clearly see, nodes on the network that accept them have a clear path to relay them to the miners. Two nodes attempting to limit transaction propagation across the network will not affect the final receipt by the miner node.

In this diagram, we see that almost half of the sample network has a filtering policy for this class of transactions. Nevertheless, only a portion of the network propagating these transactions is blocked from the path to the miner. The remaining nodes without filtering still have a clear path to the miners. This introduced some degree of friction in a subset of users, but allows other users to freely engage in the propagation of these transactions.

Even users affected by filtering nodes require only a single connection to the rest of the network node (or direct connection to the miner) that is not detached from the miner to remove that friction. If your actual relay network has a similar configuration to this example, then it is all you need to do is a single new connection to mitigate the problem.

In this scenario, only a small number of networks are actually propagating these transactions. The rest of the network is engaged in policy filtering to prevent propagation. However, even in this case, the unfiltered node still has a clear path to propagate to the miners.

Only this small, small, unfiltering nodes are needed to ensure final propagation to miners. Preferred peering logic, that is, functionality to ensure that nodes prefer peer or relay policies that implement the same software version. These types of solutions can ensure that peers who propagate something to others cannot find each other and maintain connections between themselves throughout the network.

Tolerant minority

As you can see these different examples, even in the face of the overwhelming majority of public networks engaged in filtering certain classes of transactions, what is needed to successfully propagate through the network to miners is the small number of networks that propagate and relay them.

These nodes essentially create “subnetworks” within the larger public relay network through technical mechanisms, ensuring that from users engaged in these types of transactions there is a viable path to minors who are willing to include them in the block.

There is essentially nothing you can do to counter this dynamically, except for carrying out a civil attack on all these nodes. Also, a cibil attack requires a single honest connection to be completely defeated. Similarly, honest nodes that create very large numbers of connections with other nodes on the network can increase the cost of such civil attacks to the de-capacity. The more connections you create, the more civil nodes you need to spin in order to consume all the connection slots.

What if there are no minorities?

So what happens if there are no tolerant minorities? In that case, what happens to transactions in this class?

If users still need to create them and pay the miner, they will be confirmed. Minor simply sets up the API. The role of miners is to confirm the trade, and the reason they do so is to maximize profits. Miners are not selfless, not moral or ideologically motivated, they are business. They exist to make money.

If there are users who are willing to pay for a particular type of transaction, and the entire public relay network refuses to propagate those transactions to miners to include them in the block, the miners create another way for users to submit those transactions to them.

It’s a reasonable move to make as a profit motivating actor when there are customers who want to pay you.

Relay policies are not a consensus alternative

At the end of the day, if the relay policy is consensus in effect, the relay policy cannot successfully censor the transaction if the user is willing to pay. Miners have no extended status such as the user’s willingness to pay (such as spending time checking damage or savings to nodes on the network, i.e. time on consumer PCs, etc.).

If some classes of transactions are deemed truly undesirable by Bitcoin users and node operators, there is no solution to stop them from being seen on blockchains approaching enacting and disabling consensus changes.

If filtering policies implemented in relay networks can prevent transactions from being seen, then Bitcoin will not be able to withstand censorship.