On mempool policy consistency



Summary:

In a recent discussion on bitcoin-dev, David A. Harding pointed out that a 95% chance of having an outbound peer accept a transaction implies 1 in 20 payments will fail to propagate on their initial broadcast. However, the impact of this depends on how easy it is to retry and how likely the retry is to succeed after a failure. It is conceivable that a 5% failure rate could be detectable and automatically rectified, but a good solution has not been proposed yet in a way that is efficient, private, and decentralized.According to napkin math presented in the discussion, there are about 250,000 transactions per day, which rounds up to 100 million per year. Assuming we only want one transaction per year to fail to initially propagate on a network where 30% of nodes have adopted a more permissive policy, lightweight clients will need to connect to over 50 randomly selected nodes. To achieve a target failure probability of 1-in-1e8, different numbers of connections are needed depending on the success target and whether preferential peering is used. For example, with 24 connections (where everyone running a long-lived node is listening), you need ~54% of listening nodes to support your tx's features in most reasonable scenarios. If a more permissive policy is only adopted by 10% of nodes, then a lightweight client needs to connect to almost 150 nodes. For this scenario, 175 connections would be needed or 153 with a target failure rate of 1-in-10-million.


Updated on: 2023-05-22T22:16:31.022375+00:00