When does Bitcoin’s mempool policy become network policy?

[Antidote47k]

Bitcoin’s consensus rules are intentionally difficult to change but when it comes to mempool policy, it’s a different layer, individual nodes are free to choose what transactions to accept and relay, but when you think about it most nodes don’t operate with completely unique policies, they still tend to follow Bitcoin core’s defaults. wallets, applications and developers often build around those expectations too.

So this got me thinking, at what point does widespread policy convergence start having network wide effects? Suppose a transaction is consensus valid but it’s doesn’t satisfy the policy used by majority of nodes, technically the transaction is valid and nothing should stop a miner from including it in a block, however propagating that transaction to the miner in the first place could prove to be difficult if most of the network refuse to relay it.
At the same time having relatively consistent relay policies also has its advantages liking giving developers predictable behaviors and protecting nodes from the likes of excessive bandwidth and CPU/memory consumption.

My thoughts are wether it’s to gets to a point where the networks practical transaction layer becomes so reliant on common policy defaults that altering those policies could result to ramifications that transcends individual nodes.

[Ambatman]

Not quite imo
Policy can have network wide practical effect doesn't mean it has become consensus even if it looks like one
Meaning it becomes a choice.
As long as miners and alternative nodes can bypass the dominant policy
It remains a relay issue rather than a change to Bitcoin validity rule.

[d5000]

Most nodes connect to a default of 8 outbound peers, and on average you have 5 to 6 hops to reach a miner.

This results into a transaction which is rejected as "non-standard" by 80% of the nodes still has a good chance to reach a miner in a few minutes (50-60%), while the threshold of becoming unlikely, at least if you don't try for several hours, is close to a rejection by 90% (when the probability is about 10%), and 95% rejection means already near-zero success, although if you try for several hours you have a slight chance due to peer rotation.

Of course you could try to use a client like LibreRelay to preferrently connect to nodes with lax policy settings. Or use a Slipstream-type service to  mining pools themselves.

So I think the conclusion is that the majorities can influence the transaction behavior via mempool policy, but they can't censor completely, you will find always ways around if you really want. This is of course also the essence of the OP_RETURN/BIP-110 issue.

[Upgrade00]

Suppose a transaction is consensus valid but it’s doesn’t satisfy the policy used by majority of nodes, technically the transaction is valid and nothing should stop a miner from including it in a block, however propagating that transaction to the miner in the first place could prove to be difficult if most of the network refuse to relay it.

I cannot think of any situation now where that would happen. Even ordinals/runes which clog ul the network gets propagated and confirmed, you'll have to be doing something extremely unusual to wind up in such a situation where your transaction is excluded from majority of nodes

[Cookdata]

Bitcoin’s consensus rules are intentionally difficult to change but when it comes to mempool policy, it’s a different layer, individual nodes are free to choose what transactions to accept and relay, but when you think about it most nodes don’t operate with completely unique policies, they still tend to follow Bitcoin core’s defaults. wallets, applications and developers often build around those expectations too.

I don't think consensus rules are difficult to change, the difficulty is in the agreement of nodes and miners to accept the changes and how it is going to affect the network. If it's a safe change that is going to improve the network, there wouldn't be a difficulty unless otherwise. Most often, people don't have problems with consensus rules, it's always the nodes rules, and with what I have seen, the disagreement has always been a difference in individual views and maybe some psycho developers that don't know when to quit. I believe you saw the recent fork this month, some of them have gone back to core, while some are still delutional with their failure

So this got me thinking, at what point does widespread policy convergence start having network wide effects? Suppose a transaction is consensus valid but it’s doesn’t satisfy the policy used by majority of nodes, technically the transaction is valid and nothing should stop a miner from including it in a block, however propagating that transaction to the miner in the first place could prove to be difficult if most of the network refuse to relay it.

The majority of nodes can reject a transaction that does not meet their policy rules, but the network does not completely stop anyone who wants to make transactions that are not the majority node standards. There are some miners that accept transactions that are not even core standard, they will accept it as long as you can pay the fee for them to include the transaction in the next block. But come to think of it, when you see a particular nodes are been dominated in numbers, don't you think it's for the security of everyone in the network. There is absolutely no way a particular node policy will outnumber other nodes if they do not agree to those rules, and it doesn't make sense to change it just because another person disagrees with it, but even at that, you have the option to submit it directly to a miner without relay to other nodes that may reject your transaction.

[Mia Chloe]

~snip

Well personally I think the distinction here is important. Even if most nodes follow Bitcoin Core’s default policy that doesn’t turn the policy into consensus. A transaction that doesn’t meet those policies can still be perfectly valid and mined if a miner gets it through another route.

One kinda interesting part is the propagation layer where if almost everyone rejects or refuses to relay certain transactions it could actually become much harder for those transactions to reach miners through the normal network. So I’d say the concern isn’t really that mempool policy becomes  practical consensus. This particular POV kinda reminds me about the difference between knots and core.

[pooya87]

As long as bitcoin core doesn't enforce a monopoly by default where it rejects connection to any other node that doesn't have the same mempool (eg. blocking nodes based on compact block size claiming it is "to speed up network wide block propagation") the answer is no. "Memepool policy" remains individual node preference not a network-wide consensus rule.

[Danish Ali]

Technically, of course, there are always ways to bypass a policy, just talk to the miner, set up a permissive policy relay client or whatever. I believe it is more a response to the consequence, I mean, I think that would probably be the consequence which has been raised.

Majority Policy as soon as "getting your tx mined" turns into a paid service or you need to be able to know which alternate route to take, majority policy becomes ineffective. Not consensus but it has now become a toll. If someone is not aware of the workarounds, then he accepts the policy, if someone is knowledgeable enough, then he goes around it. This is a pure "network effect" without even having to do with validity rules.