What should be the intended purpose of (mempool) policy defaults in a full-node implementation like Bitcoin Core?

First of all, it’s worth noting that at the time of writing (February 2024) there seems to be some disagreement on this.

instagibbs said in his policy zoo document:

There are N motivations for any policy that I know of.

Anti-DoS: Only “cheap” items to be verified are flooded into the network.

Security: Certain types of transactions can break certain systems without good reason.

Upgrade Hooks: Put a few things in a “prohibited” state so that if you find a use for them later, they don’t “seize” your funds by refusing to forward them, such as spending or pre-signed transactions.

Pro-decentralization: Makes it simple and cheap for miners to build expensive blocks.

Paternalism: We want wallet creators to use the least amount of public resources while achieving their end goal (unless that goal is a “network attack”!).

Secure soft fork process: Sometimes the only mechanism to prevent non-upgraded miners from mining blocks that are considered invalid by upgraded miners (but considered valid by non-upgraded miners) is thwarting policy. no see.

Allow people to pay a fee to make transactions on acceptable APIs

All of these motivations must obviously be weighed against the fact that Bitcoin miners want to make transactions, and miners want fees from those transactions. Ideally we create a mempool/relay system where both can achieve relative harmony.

This serves two purposes Suhas intended in his Stack Exchange post:

The purpose of policy checking is generally to (a) block DoS vectors and (b) proactively prevent relaying of transactions that violate future consensus changes, thereby making deploying future consensus changes more secure.

Gloria Zhao’s presentation on “Transaction Relay Policies for L2 Developers” at Adopting Bitcoin 2021 discussed the difference between protecting Bitcoin users from attacks (e.g. CPU exhaustion) and maximizing the reliability of fee bumping for the L2 protocol. Talk about balance.

So far, these views appear to be relatively consistent, although there may be some differences in priorities.

There is a greater disagreement among those who believe that policies should be used as a tool to limit the propagation of certain use cases (ordinal, inscription, etc.) and that policies should be used even when the transaction in question is consensual and has a high commission rate. Luke Dashjr also takes the following view: X) that:

“Transaction locking” AFAIK is a result of policy centralization efforts and not the real problem. An alternative is to encourage a variety of policies and prepare several alternative transaction variants so that transactions rejected at the technical level do not become problematic.

This suggests that there is disagreement about whether the default (mempool) policy should be standardized across full node implementations to achieve its intended purpose. Full node operators are always free to change defaults (policies are not consensus), but standardization in this case means consistent defaults across different implementations.