In the last Mempool article, I went over the different forms of relay policy filters, which is why they are found, and the incentives that ultimately decide how effective each class of filter is to prevent confirmation of different classes of transactions. In this piece, I look at the dynamics of the relay network when some nodes on the network run different relay policies compared to other nodes.
All else being equal, when nodes on the network run homogeneous relay policies in their Mempools, all transactions should spread throughout the network as they pay the minimum necessary not to be thrown from a nodes mempool in times of large transactions baclogs. This changes when different nodes on the network run heterogeneous policies.
Bitcoin Relay Network works on a best effort using what is called a flood architecture. This means that when a transaction is received by a knot, it is forwarded to any other knot, it is connected to the except the one from which it received the transaction. This is a very ineffective network architecture, but in connection with a decentralized system, it gives a high degree of guarantee that the transaction will eventually reach its intended destination, miners.
Introduction of filters in a nodes relay policy to limit the transmission of otherwise valid transactions in theory introduces friction to the spread of this transaction and impair the reliability of the network’s ability to perform this function. In practice, things are not that simple.
How much friction prevents propagation
Let’s look at a simplified example of different networking compositions. In the following graphics, blue nodes represent those who will Forming some arbitrary class of consensus -encompassing transactions, and red nodes represent those who will not Spreading these transactions. The collective set of miners is referred to in the center as a simple representation of where transactive users ultimately want their transactions to be run to eventually be confirmed in Blockchain.
This is a model of the network where the nodes that refuse to spread these transactions are a clear minority. As you can clearly see, any knot on the network that accepts them has a clear path to forward them to miners. The two nodes that try to limit transaction distribution across the network have no influence on their possible reception of the miners’ nodes.
In this chart you can see that almost half of the example -network introduces filtration policies for this class of transactions. Despite this, only part of the network that propagates these transactions is cut off from a path to miners. The rest of the nodes that do not filter still have a clear path for miners. This has introduced a certain degree of friction for a subgroup of users, but the others can still freely engage in disseminating these transactions.
Even for the users affected by filtration of nodes, only a single connection to the rest of the network nodes that are not cut off from miners (or a direct connection to a miner) for this friction to be removed. If the real relay network should have a similar composition as this example, all it would take is a single new connection to relieve the problem.
In this scenario, only a small minority of the network actually spreads these transactions. The rest of the network participates in filtration policies to prevent their propagation. Even in this case, however, they have nodes that do not filter, still a clear path to spread them to miners.
Only this small minority of non-filtering nodes is needed to ensure their possible propagation to miners. Preferred peering logic, ie. Functionality to make sure your knot prefers comrades who implement the same software version or relay policies. These types of solutions can guarantee that comrades who will spread something to others do not find each other and maintain connections among themselves across the network.
The tolerant minority
As you can look at these different examples, even in the light of an overwhelming majority of the public network participating in filtering a particular class of transactions, all that is needed for them is to be propagated across the network to miners, a small minority of the network to spread and forward them.
These nodes will essentially through any technical mechanism create a “sub -network” within the larger public relay network to guarantee that there are viable paths from users participating in these types of transactions to miners who are willing to include them in their blocks.
There is essentially nothing that can be done to address this dynamic except to participate in a Sybil attack on all these nodes, and Sybil attacks only need a single honest connection to be completely defeated. An honest knot that creates a very large number of connections with other nodes on the network can also raise the cost of such a Sybil attack exorbitant. The more compounds it creates, the more Sybil hubs have to be spun to consume all its connecting places.
What if there is no minority?
So what if there is no tolerant minority? What will happen to this class of transactions in this case?
If users still want to make them and pay fees to miners for them they will be confirmed. Miners will simply create an API. The role of miners is to confirm transactions and the reason they do is to maximize the profits. Miners are not selfless units or morally or ideologically motivated, they are a business. They exist to make money.
If users are found that are willing to pay them money for a particular type of transaction, and the entire public relay network refuses to spread these transactions to miners to include them in blocks, miners will create another way for users to submit these transactions to them.
It is simply the rational step to do as a profit motivated actor when customers are found who want to pay you money.
Relay policy is not a substitute for consensus
At the end of the day, relay policy cannot successfully censor transactions, if they are consensus -valid, users are willing to pay for them, and miners have no mitigating circumstances to reject the fees that users are willing to pay (such as causing material damage or damage to the nodes on the network, Pc.).
If some class of transactions is really seen as unwanted by Bitcoin users and knot operators, there is no solution to prevent them from being confirmed in blockchain without adopting a consensus change to make them invalid.
If it was possible to simply prevent transactions from being confirmed by filtering policies implemented on the relay network, Bitcoin would not be censorship.