In the last MEMPOOL article, I went through the dynamics of transaction spread when different nodes on the network run different MEMPOOL -Relay policies. In this piece, I look at the dynamics of private Mempools and the implications that have for the applicability of the public mempool, mining principles and the Helcoin network’s health in general.
In the heart of the purpose of Mempool is to facilitate the customized incentives from two different parties, miners and trading in users. Users want to act and are willing to pay miners’ transaction fees to do so. Miners want to make money, and transaction fees are an additional source of income in addition to the new coin supplement in each block, as well as a necessary primary source of income to cultivate in the long term when the subsidy decreases.
Bitcoin is a system secured with incentives. This core dynamics is what drives the system’s safety, you have a customer (s) and a provider, and the two who try to meet their wishes and needs is what ensures that blockchain continues to cross with a sufficient amount of thermodynamic security.
Attempts to introduce friction into this relief mechanism do not ultimately do anything at all to change the incentives of these two parties. A user who wants to make a particular form of transaction will still want to make this transaction and pay for it. A miner willing to accept such transactions will still want to accept them and collect the fee by including them in a block.
If the transaction is valid, these two parties will still have their unfulfilled wishes and needs, and will still be strongly motivated to meet them in some form or way.
Miner API
Individual end users are not necessarily activated enough or competent enough to route around friction artificially introduced between both ends of a coincidence of wishes, but miners are certain. When the old saying goes, “If you build it they come.”
The preferred situation for miners is obviously acquiring fee -paying transactions in the tape through the public mempool. It requires the lowest overhead possible for them to simply run a standard Bitcoin client out of the box, it is a very elastic reproduction mechanism that ensures a very high degree of reliability to get miners to the highest fee that pays transactions and they do not have to do anything. Just download the client and run it.
In a very hostile environment, such as a network broad effort to filter consensus Valid transactions during their propagation across the network, the traditional assumption may be in doubt.
In such a scenario, miners have any incentive to create out-of-band mechanisms to accept transactions that are not properly forwarded across the network. Marathon’s slipstream API for non-standard transactions is not the only example of this. In fact, there is a prolonged precedent from almost ten years ago that was widely implemented by many mining pools and still exists today. Transaction accelerators.
We now live in a world of full-RBF where any transaction, regardless of using the historic “opt-in” flag, can be Gebun. Any knot that has upgraded to FULL-RBF passes on any transaction that uses an unconfirmed output already pending in MEMPOOL as long as it pays a higher fee. This has not always been the case. Historically, only transactions that were initially made with a flag to sign up for RBF use could be replaced and expected to spread over the network.
Transaction accelerators were created by miners to facilitate this behavior for transactions that did not choose RBF use.
Third -party APIs
While overhead is not exorbitant high for a miner or pool to create their own API in transaction submission, it is not free. It still requires at least one developer and time to review the design and release cycle of any piece of software. The curve is not very exaggerated, but it favors ever -greater miners over less in terms of how many resources they will have to devote to such an endeavor.
Mempool.Space has proven that it is a viable endeavor for a third party not related to miners to create such API, giving miners the opportunity to simply connect to their service rather than using the efforts to create one from scratch. However, this has its problems, such a third party will not build and operate such service for free. They want their cut.
There are two ways this dynamic can go, whether these services end up requiring a higher cost to allow both miners and service providers to earn revenue, or miners will have to share a minor cut of revenue for such services to remain competitive with direct miner -operated. This means that miners who use a third -party submission API rather than their own will earn less revenue than miners who drive their own API.
Private order current
One of the above options introduces serious problems when it comes to the overall system incitaments, the reliability of end -user software and potentially even the security model for other layering systems that depend on the use of preoccupied transactions and a reactive security model to keep user funds secure.
When transactions are submitted to a private API, they are not visible to network participants until they are actually confirmed in a block. The entire queue of unconfirmed transactions that make use of these systems is opaque. This could be published by the operators of these APIs, but not in a confidence -free way. There is no way to prove or guarantee that operators do not withhold information.
Putting of transactions from a public point of view may distort fee stimations that users make, and even open the door to the possibility of manipulating these fearkers by filling blocks with their own transactions. Transactions used in the operation of second layer systems could be withheld from public display until confirmation, which may delay users’ ability to respond to transactions they must answer to guarantee the security of their funds.
Finally, it is a massive centralization pressure, just the existence of such APIs if the demand or need for them is high enough. Having to deal with connection to each API to submit a transaction is a hassle, bad UX and potential back end -complexity. This tends to strengthen the use of the largest API (s) and ignore the tails, creating a feedback loop.
The API operators with the biggest hash rate will have the fastest and most reliable confirmations, which guarantees that only the largest miners reliably earn this extra income, giving them more capital to get bigger, etc.
Parallel Mempools
At the other end of the spectrum is the possibility of creating completely independent public baton. Although this is repeating the current openness to the existing public mempool and avoids the worst of centralizing pressure from central APIs, it is still not ideal.
Having more Mempools that introduce complexity for miners, end users and for end -user applications. Users now have to keep track of all the independent mempools, especially those used for systems they interact with that are not propagated by the primary relay network to get an overview of uncommoned transactions.
If lightning (or another layer 2) were to start using a parallel Mempool, it would be critical for any user of lightning (or the other layer 2). It would also be necessary to track all of the parallel baton to have an accurate overview of the other unconfirmed transactions you offer for admission to the next block. Tracking Only a subgroup of them would lead to potentially large margins in any user fee determination.
You just make things worse
It’s just not possible to try to prevent transactions with willing fees that pay users without tackling them at the consensus level. Bitcoin is an engine powered by incentives and when the incentives from several parties adapt to, they will be relieved in some form.
Attempts to pretend that this is not the case and that things can be stopped, increased or otherwise delayed is a fool’s errand. Not only that, but to try on every serious scale come with very serious negative consequences, in addition to being doomed to fail.
Bitcoin’s consensus rules are the framework where incentives are played. The only thing that can trump incentives is to change that frame. It is literally what informs and forms the incentives in the first place.
Trying to interfere with these incentives in any other layer is a fool’s errand and can only do anything but aggravate the negative results driven by incentives, ie. Centralization.