In the last Mempool article, we experienced transaction propagation dynamics when different nodes on the network are running different Mempool relay policies. In this work, we look at the dynamics of the private memo pool and its meaning in the utility of public members, mining incentives, and the health of the overall Bitcoin network.
At the heart of Mempool’s purpose is promoting integrity incentives for two different parties, miners and trading users. Users want to trade and are willing to pay miners’ transaction fees to do so. Miners want to make money, and transaction fees are an additional revenue stream, along with new coin subsidies for each block, and the main revenue stream needed to cultivate in the long term as subsidies decrease.
Bitcoin is a system protected by incentives. This core dynamics promotes system security, with customers and providers. The two attempt to meet their desires and needs ensure that the blockchain continues to move forward with enough thermodynamic security.
If we try to introduce friction into this facilitation mechanism, we will ultimately do nothing to change the incentives of these two parties. Users who want to create a specific type of transaction want to make that transaction and pay for it. Miners who are willing to accept these types of transactions will want to collect fees by accepting them and including them in the block.
If the transaction is in effect, these two parties will have unmet needs and needs that are yet to be met and will be strongly motivated to meet them in some form or fashion.
Minor API
While individual end users are not necessarily sufficiently capitalized to route around friction artificially introduced between the two ends of a chance of desire, miners are undoubtedly. As the old saying goes, “If you build it, they will come.”
The priority situation for miners is clearly to acquire fee payment transactions at the bank through public memory. Simply run a standard Bitcoin client out of the box and requires the lowest possible overhead. This is a very resilient propagation mechanism, ensuring very high reliability and nothing has to be done to get the trade that pays the best fees to miners. Simply download and run the client.
However, in highly adversarial environments such as a wide network effort to filter effective transactions during network-wide propagation, its traditional assumptions can be questioned.
In such a scenario, the miners have all the incentives to set up an out-of-band mechanism to accept transactions that are not properly relayed across the network. The marathon slipstream API for non-standard transactions is not the only example of this. In fact, there is a long-standing precedent of nearly ten years ago, almost ten years ago, which was widely implemented by many mining pools, and it remains to this day. Transaction accelerator.
We currently live in a full RBF world. Here, transactions can still pay for the historical “opt-in” flag. Nodes upgraded to Full-RBF relay transactions that are already spending unconfirmed output on hold in Mempool as long as they pay a higher fee. This wasn’t necessarily the case. Historically, it was expected to exchange only transactions created with flags to opt in to use RBF and propagate across the network.
Transaction accelerators were created by miners to facilitate this behavior of transactions that did not opt-in to use RBF.
Third Party APIs
The overbits for miners and pools to create their own transaction submission APIs are not very high, but they are not free. It takes at least one developer and time to go through the software design and release cycle. The curve is not particularly exaggerated, but in terms of how much resources need to be spent on such efforts, it still favors larger miners than smaller miners.
Mempool.space proves that creating such APIs is a viable effort for third parties not related to miners, allowing miners to simply connect to services rather than spending their efforts to create themselves from scratch. However, this has a problem. Such third parties will not build and operate such services for free. They’ll want their cut.
There are two ways to advance this dynamic. These services require higher costs to allow both miners and service providers to acquire revenue, or miners must share lower revenues in order for such services to remain competitive directly with miners. This means miners use third-party submission APIs rather than making less revenue than miners running their own APIs.
Private Order Flow
Any of the above possibilities poses serious problems, even security models that rely on system-wide incentives, end-user software reliability, and the use of pre-signed transactions and reactive security models to keep user funds safe.
Once a transaction is submitted to a private API, it is invisible to network participants until it is actually confirmed in the block. The entire queue of unconfirmed transactions using these systems is opaque. This could be exposed by the operators of these APIs, but it cannot be published in an unreliable way. There is no way to prove or guarantee that the operator has not withheld the information.
Withholding transactions from the public view can distort the fee estimates you create, and even open the door to the possibility of manipulating those fear rates by packing your own transactions into blocks. Transactions used to operate the second layer system may be withheld from publication to confirmation. This allows users to delay their ability to respond to transactions that they need to deal with in order to ensure the security of their funds.
Finally, if their demand or need is high enough, the only thing the presence of such APIs is a massive concentration pressure. Handling connections to individual APIs and sending transactions is a hassle, poor UX and potential backend complexity. This enhances the use of the largest API, tends to ignore tail ends, and creates a feedback loop.
API operators with the largest hashrate have the fastest, most reliable confirmation, guaranteeing that only these biggest miners will make this extra revenue, giving more capital and more.
Parallel Mempool
At the other end of the spectrum, it is possible to create a completely independent public relay network. This replicates the current openness of existing public memory and avoids the worst state of centralized pressures in central APIs, but still not ideal.
There are multiple Mempools that introduce complexity to minor, end-user, and end-user applications. To view unconfirmed transactions, users should track all independent memory, especially all independent memory used by systems that are not propagated on the primary relay network.
If a lightning bolt (or other layer 2) begins to use parallel members, tracking it is important for users of lightning bolt (or other layer 2). You also need to track it all A parallel relay network to accurately view other unconfirmed transactions that you have bid for inclusion in the next block. Tracking only a subset of them results in a potentially large margin of error in user fee estimates.
You’re just making things worse
It is impossible to try to prevent transactions with an ambitious fee that addresses the user without addressing it at a consensus level. Bitcoin is an incentive-powered engine that is somehow facilitated when multiple parties’ incentives match.
It’s a fool’s business to be able to stop, eliminate, or delay things, be careful. Not only that, trying on a serious scale has very serious negative consequences, in addition to being destined to fail.
Bitcoin consensus rules are frameworks in which incentives are played. The only thing that can win an incentive is to change that framework. It literally informs and shapes incentives in the first place.
Trying to interfere with these incentives in other groups is a fool’s errand and can only exacerbate the negative consequences caused by incentives, namely centralisation.
This post Bitcoin Mempool: Private Mempools was first published in Bitcoin Magazine and written by Shinobi.
