Bitcoin Mempools – Private Mempools

Then, you can get started. last Mempool articleI looked at the dynamics of the transaction propagation for different network nodes that have different mempool policies. I will be looking into the dynamic of private pools and how it affects the use of the public pool, mining incentives and overall the health of Bitcoin’s network. 

The mempool’s primary purpose is to align the incentives of miners and users who transact. The users want to be able to make transactions and will pay the transaction fees charged by miners to facilitate this. Transaction fees provide an alternative revenue stream to the coin subsidies in every block. They are also a primary source for long-term revenue as the subsidy is dwindling. 

Bitcoin is a secure system because of incentives. The core dynamics of Bitcoin are what drive the system’s security. You have customers and providers, who both try to meet their needs and wants. 

The attempts to add friction to this mechanism of facilitation do not change anything in the end to alter these incentives. Users who want to perform a particular type of transaction will still be willing to pay to do so. Miner’s who are willing to accept these types of transactions will want to do so and to collect fees by including the transaction in a block. 

Even if a transaction is valid, both parties still will have needs and unmet desires, which they are strongly motivated to address. 

Miner API

The end user is not always well-capitalized or skilled enough to avoid friction that has been artificially created between two ends due to a coincident of needs, but the miners are. According to the old saying, “if you build it, they will come.”

Miners will always prefer to get fee-paying transaction in band through the mempool. This requires them to have the least overhead, as they can simply run the standard Bitcoin client. It is also a highly reliable propagation system that guarantees a high level of reliability when it comes to getting the miners the most fee paying transactions. Simply download and run the client. 

In a hostile environment, like a large-scale effort to filter valid transactions by consensus during their transmission across the network this traditional assumption may be questioned. 

If this is the case, miners will be compelled by their own interests to implement out-ofband mechanisms that accept transactions not being properly relayed over the network. Marathon’s Slipstream is not the first example. It is true that there was a widely used precedent almost ten year ago. mining poolsTransaction Accelerators. Transaction accelerators. 

In the Full-RBF world, any transaction is possible, regardless of whether it uses historical or current data. “opt-in” Flag can be bumped in fee. If a node has been upgraded to Full RBF, it will forward any transaction which is spending an output that was not confirmed and is already in the mempool so long as they pay a higher rate. Historically, this hasn’t always been true. Only transactions made initially with the flag of opting in to RBF could be substituted and were expected to spread across the entire network. 

Miners created transaction accelerators to make it easier for those transactions to be processed that do not use RBF. 

Third-Party APIs

The overhead for creating a transaction submission API is not prohibitively high, but it’s still not free. To design, test and then release any software requires at minimum one developer. It’s not an exaggerated curve, but the larger miner will still have more resources to dedicate to this endeavor. 

Mempool.space proved that it was possible for a non-miner to build an API. This allowed miners the option to connect directly to this service, rather than having to spend time and effort creating one from scratch. The downside is that a company like this will not build or operate a similar service for nothing. The third party will demand a cut. 

The dynamic of this can be interpreted in two different ways. Miners could either have to pay a larger cost for these services in order to generate revenue both from the miner and the service provider, or they may need to split a smaller revenue share in order to maintain the same level of competition as directly miner run services. The miners who use a third-party submission API instead of their own API will make less money than those using their own API. 

Private Orders Flow

The above scenarios could cause major problems for the system’s incentives, the reliability of software used by end users, and even the security models of second-layer systems, which rely heavily on pre-signed transaction and reactive security to protect user funds. 

The network is not notified of transactions submitted through a private API until the block has been confirmed. This means that the entire list of transactions using these systems, which are not confirmed yet, is inaccessible. Operators of APIs could publish this, but it would not be done in an untrustworthy manner. No way can be proved or guaranteed that information is not being withheld by operators. 

By hiding transactions, users could make inaccurate fee estimations and open themselves up to manipulation by adding their transactions into blocks. Public view of transactions in second layer systems may be delayed until the confirmation of the transaction. Users will then have to wait longer to respond to the transaction. 

The mere existence of these APIs, if they are in high demand or needed by the business is enough to create a huge centralization burden. It is difficult to connect to multiple APIs to complete a single transaction. This can lead to poor UX as well as potential complexity on the backend. It tends to encourage the use of large APIs and ignore the tailend. This creates feedback loops. 

These APIs with the greatest hashrate will receive faster and more reliable confirmations. They can then earn extra money, allowing them to continue growing. 

Parallel Mempools

A totally independent network of public relays is also possible. Although this replicates current mempool openness, while also avoiding central APIs’ worst centralizing effects, it is still not perfect. 

Multiple mempools introduce complexity to miners, end users and end-user applications. In order to view unconfirmed transaction, users must now keep track of the mempools that they use, including those used by systems with which they are in contact but not transmitted over the main relay network. 

Tracking a parallel memory pool would be crucial for Lightning users (or other Layers 2) if Lightning or another Layer 2 started using it. Tracking would be required. The following are some of the most effective ways to improve your own personal effectiveness. You need to know the details of all the unconfirmed transaction you will be bidding on for the inclusion of your block. If you only track a small subset, there could be large errors in your estimation of the users fees. 

It’s only going to make things worse

It is not possible to stop transactions that are willingly paid for by users, without first addressing the issue at a consensus level. Bitcoin is a system driven by incentives. If the incentives are aligned between multiple parties, then transactions will occur. 

A fool’s mission is to deny this and try to convince yourself that you can stop things, reduce their impact, or delay them in any other way. It is also a fool’s errand to try to pretend that this cannot be the case, or to think you can stop, disincentivize, or otherwise delay things. 

Bitcoin’s consensus is the frame in which all incentives take place. Only a change in the framework can override incentives. This is what shapes and informs the incentives. 

It is foolish to try and interfere with these incentives on any other level. This will only exacerbate negative results driven by incentives. centralization.