Bitcoin Magazine
The Bitcoin Mempool: Relay Network Dynamics
In the last Mempool article, I went over the different kinds of relay policy filters, why they exist, and the incentives that ultimately decide how effective each class of filter is at preventing the confirmation of different classes of transactions. In this piece I’ll be looking at the dynamics of the relay network when some nodes on the network are running different relay policies compared to other nodes.
All else being equal, when nodes on the network are running homogenous relay policies in their mempools, all transactions should propagate across the entire network given that they pay the minimum feerate necessary not to be evicted from a node’s mempool during times of large transaction backlogs. This changes when different nodes on the network are running heterogenous policies.
The Bitcoin relay network operates on a best effort basis, using what is called a flood-fill architecture. This means that when a transaction is received by one node, it is forwarded to every other node it is connected to except the one that it received the transaction from. This is a highly inefficient network architecture, but in the context of a decentralized system it provides a high degree of guarantee that the transaction will eventually reach its intended destination, the miners.
Introducing filters in a node’s relay policy to restrict the relaying of otherwise valid transactions in theory introduces friction to the propagation of that transaction, and degrades the reliability of the network’s ability to perform this function. In practice, things aren’t that simple.
Let’s look at a simplified example of different network node compositions. In the following graphics blue nodes represent ones that will propagate some arbitrary class of consensus valid transactions, and red nodes represent ones that will not propagate those transactions. The collective set of miners is denoted in the center as a simple representation of where transacting users ultimately want their transactions to wind up so as to eventually be confirmed in the blockchain.
This is a model of the network in which the nodes refusing to propagate these transactions are a clear minority. As you can clearly see, any node on the network that accepts them has a clear path to relay them to the miners. The two nodes attempting to restrict the transactions propagation across the network have no effect on their eventual receipt by miners’ nodes.
In this diagram, you can see that almost half of the example network is instituting filtering 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 not filtering still have a clear path to miners. This has introduced some degree of friction for a subset of users, but the others can still freely engage in propagating these transactions.
Even for the users that are affected by filtering 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) is necessary in order for that friction to be removed. If the real relay network were to have a similar composition to this example, all it would take is a single new connection to alleviate the problem.
In this scenario, only a tiny minority of the network is actually propagating these transactions. The rest of the network is engaging in filtering policies to prevent their propagation. Even in this case however, those nodes that are not filtering still have a clear path to propagate them to miners.
Only this tiny minority of non-filtering nodes is necessary in order to ensure their eventual propagation to miners. Preferential peering logic, i.e. functionality to ensure that your node prefers peers who implement the same software version or relay policies. These types of solutions can guarantee that peers who will propagate something to others won’t find each other and maintain connections amongst themselves across the network.
As you can see looking at these different examples, even in the face of an overwhelming majority of the public network engaging in filtering of a specific class of transactions, all that is necessary for them to successfully propagate across the network to miners is a small minority of the network to propagate and relay them.
These nodes will essentially, through whatever technical mechanism, create a “sub-network” within the larger public relay network in order to guarantee that there are viable paths from users engaging in these types of transactions to the miners willing to include them in their blocks.
There is essentially nothing that can be done to counter this dynamic except to engage in a sybil attack against all of these nodes, and sybil attacks only need a single honest connection in order to be completely defeated. As well, an honest node creating a very large number of connections with other nodes on the network can raise the cost of such a sybil attack exorbitantly. The more connections it creates, the more sybil nodes must be spun up in order to consume all of its connection slots.
So what if there is no Tolerant Minority? What will happen to this class of transactions in that case?
If users still want to make them and pay fees to miners for them, they will be confirmed. Miners will simply set up an API. The role of miners is to confirm transactions, and the reason they do so is to maximize profit. Miners are not selfless entities, or morally or ideologically motivated, they are a business. They exist to make money.
If users exist that are willing to pay them money for a certain type of transaction, and the entirety of the public relay network is refusing to propagate those transactions to miners in order to include them in blocks, miners will create another way for users to submit those transactions to them.
It is simply the rational move to make as a profit motivated actor when customers exist that wish to pay you money.
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 do not have some extenuating circumstances to turn down the fees users are willing to pay (such as causing material damage or harm to nodes on the network, i.e. crashing nodes, propagating blocks that take hours to verify on a consumer PC, etc.).
If some class of transactions is truly seen as undesirable by Bitcoin users and node operators, there is no solution to stopping them from being confirmed in the blockchain short of enacting a consensus change to make them invalid.
If it were possible to simply prevent transactions from being confirmed by filtering policies implemented on the relay network, then Bitcoin would not be censorship resistant.
This post The Bitcoin Mempool: Relay Network Dynamics first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
The Bitcoin Mempool: Relay Network Dynamics
In the last Mempool article, I went over the different kinds of relay policy filters, why they exist, and the incentives that ultimately decide how effective each class of filter is at preventing the confirmation of different classes of transactions. In this piece I’ll be looking at the dynamics of the relay network when some nodes on the network are running different relay policies compared to other nodes.
All else being equal, when nodes on the network are running homogenous relay policies in their mempools, all transactions should propagate across the entire network given that they pay the minimum feerate necessary not to be evicted from a node’s mempool during times of large transaction backlogs. This changes when different nodes on the network are running heterogenous policies.
The Bitcoin relay network operates on a best effort basis, using what is called a flood-fill architecture. This means that when a transaction is received by one node, it is forwarded to every other node it is connected to except the one that it received the transaction from. This is a highly inefficient network architecture, but in the context of a decentralized system it provides a high degree of guarantee that the transaction will eventually reach its intended destination, the miners.
Introducing filters in a node’s relay policy to restrict the relaying of otherwise valid transactions in theory introduces friction to the propagation of that transaction, and degrades the reliability of the network’s ability to perform this function. In practice, things aren’t that simple.
How Much Friction Prevents Propagation
Let’s look at a simplified example of different network node compositions. In the following graphics blue nodes represent ones that will propagate some arbitrary class of consensus valid transactions, and red nodes represent ones that will not propagate those transactions. The collective set of miners is denoted in the center as a simple representation of where transacting users ultimately want their transactions to wind up so as to eventually be confirmed in the blockchain.
This is a model of the network in which the nodes refusing to propagate these transactions are a clear minority. As you can clearly see, any node on the network that accepts them has a clear path to relay them to the miners. The two nodes attempting to restrict the transactions propagation across the network have no effect on their eventual receipt by miners’ nodes.
In this diagram, you can see that almost half of the example network is instituting filtering 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 not filtering still have a clear path to miners. This has introduced some degree of friction for a subset of users, but the others can still freely engage in propagating these transactions.
Even for the users that are affected by filtering 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) is necessary in order for that friction to be removed. If the real relay network were to have a similar composition to this example, all it would take is a single new connection to alleviate the problem.
In this scenario, only a tiny minority of the network is actually propagating these transactions. The rest of the network is engaging in filtering policies to prevent their propagation. Even in this case however, those nodes that are not filtering still have a clear path to propagate them to miners.
Only this tiny minority of non-filtering nodes is necessary in order to ensure their eventual propagation to miners. Preferential peering logic, i.e. functionality to ensure that your node prefers peers who implement the same software version or relay policies. These types of solutions can guarantee that peers who will propagate something to others won’t find each other and maintain connections amongst themselves across the network.
The Tolerant Minority
As you can see looking at these different examples, even in the face of an overwhelming majority of the public network engaging in filtering of a specific class of transactions, all that is necessary for them to successfully propagate across the network to miners is a small minority of the network to propagate and relay them.
These nodes will essentially, through whatever technical mechanism, create a “sub-network” within the larger public relay network in order to guarantee that there are viable paths from users engaging in these types of transactions to the miners willing to include them in their blocks.
There is essentially nothing that can be done to counter this dynamic except to engage in a sybil attack against all of these nodes, and sybil attacks only need a single honest connection in order to be completely defeated. As well, an honest node creating a very large number of connections with other nodes on the network can raise the cost of such a sybil attack exorbitantly. The more connections it creates, the more sybil nodes must be spun up in order to consume all of its connection slots.
What If There Is No Minority?
So what if there is no Tolerant Minority? What will happen to this class of transactions in that case?
If users still want to make them and pay fees to miners for them, they will be confirmed. Miners will simply set up an API. The role of miners is to confirm transactions, and the reason they do so is to maximize profit. Miners are not selfless entities, or morally or ideologically motivated, they are a business. They exist to make money.
If users exist that are willing to pay them money for a certain type of transaction, and the entirety of the public relay network is refusing to propagate those transactions to miners in order to include them in blocks, miners will create another way for users to submit those transactions to them.
It is simply the rational move to make as a profit motivated actor when customers exist that wish to pay you money.
Relay Policy Is Not A Replacement 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 do not have some extenuating circumstances to turn down the fees users are willing to pay (such as causing material damage or harm to nodes on the network, i.e. crashing nodes, propagating blocks that take hours to verify on a consumer PC, etc.).
If some class of transactions is truly seen as undesirable by Bitcoin users and node operators, there is no solution to stopping them from being confirmed in the blockchain short of enacting a consensus change to make them invalid.
If it were possible to simply prevent transactions from being confirmed by filtering policies implemented on the relay network, then Bitcoin would not be censorship resistant.
This post The Bitcoin Mempool: Relay Network Dynamics first appeared on Bitcoin Magazine and is written by Shinobi.
Full story here:
![[DK]](/data/avatars/s/57/57999.jpg?1720990206){kind=avatar}
