The Bitcoin Mempool: Relay Network Dynamics
The post The Bitcoin Mempool: Relay Network Dynamics appeared on BitcoinEthereumNews.com. 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…
The post The Bitcoin Mempool: Relay Network Dynamics appeared on BitcoinEthereumNews.com.
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…
What's Your Reaction?
