Terminology – What is a “(mempool) policy”?

Standardization refers to a more stringent set of rules enforced by all nodes in a transaction in addition to the consensus rules. A policy is a much broader set of rules or processes that nodes follow. Unlike the standard, it is not limited to a single transaction, nor is it limited to validation rules.

Broadly speaking, policy is everything that is not a consensus. The set of rules that determine whether a block is valid is consensus. Everything else: how blocks are relayed, whether a cache of unconfirmed transactions is used to speed up transmission and verification, and how unconfirmed transactions are propagated through the network are policies. for example:

• The transaction is void due to: bitcoin consensus When the sum of output values ​​is greater than the sum of input values. (That is, the fee is less than 0.)
• The transaction is void due to: Bitcoin Core Standard If there is a fee lower than 1sat/vbyte, follow the rules.
• Sending unconfirmed transactions with more than 25 unconfirmed parent items violates the following: Bitcoin Core Policy rule.

A mempool policy is a set of rules that describe the validity of a transaction from the perspective of a node’s mempool. Perhaps the biggest difference from the standard is that it is contextual. Unconfirmed transactions may be valid according to the standard (and therefore consensus), but will still be rejected by the node’s mempool. The ancestral rule above is one such example.

However, mempools are not the only area where policy rules apply. Transaction relay, for example, is another. For example, the maximum number of transactions a node requests or announces per peer is often called a policy.

Finally, while policies may vary from node to node, not all rules are equally important. For example, a node may choose not to store and relay unconfirmed transactions that store data. OP_RETURN It outputs unconfirmed transactions or does not store and forward them at all and is still part of the network. However, you can think of some ridiculous policies a node could have (e.g. only peer finding and/or block forwarding via its own custom protocol). In this case, even if you implement all the consensus rules, you will hardly be able to keep up with the network. And in between are the corresponding expectations you might have of your network.

This is an attempted answer. In Bitcoin, terminology is notoriously confusing and people can have different views on what “policy” represents. This is just the definition I used (I used it without the spelling, thank you for asking), but I found it useful when discussing related issues with other Bitcoin developers.