<p>First of all it is worth noting there seems to be some disagreement on this at the time of writing (February 2024).</p>
<p>instagibbs stated in his <a href="https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8" rel="nofollow noreferrer">policy zoo doc</a>:</p>
<blockquote>
<p>There are N motivations for policy that I know of:</p>
<p>Anti-DoS: Only “cheap” things to validate get flooded to the network</p>
<p>Security: Certain types of transactions may mess up certain systems for no good reason</p>
<p>Upgrade hooks: We leave some things “forbidden” such that if we find a use for them later we don’t “confiscate” funds by refusing to relay e.g., a spend or pre-signed transaction</p>
<p>Pro-decentralization: Make it simple/cheap for miners to build blocks that pay well</p>
<p>Paternalism: We want wallet authors to use the least amount of public resources while still accomplishing their end goals(as long as that goal isn’t “attack the network”!).</p>
<p>Safe soft-fork process: Sometimes the only mechanism preventing an unupgraded miner from mining a block that would be considered invalid by upgraded miners (but valid by unupgraded miners) is policy discouragement.</p>
<p>Let people pay fees to make transactions in an acceptable API</p>
<p>All of these motivations obviously have to be weighed against the fact that bitcoiners want to make transactions, and miners want fees from those transactions. Ideally we make a mempool/relay system where both can live in relative harmony.</p>
</blockquote>
<p>This corresponds to two of Suhas' intended purposes in his <a href="https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c/100319#100319">Stack Exchange post</a>.</p>
<blockquote>
<p>The purpose of policy checks is generally to (a) close off DoS vectors and (b) to make future consensus changes safer to deploy, by preventing relay of transactions that would violate such future consensus changes well in advance.</p>
</blockquote>
<p>Gloria Zhao talks about the trade-off between protecting the bitcoind user from attacks (e.g. CPU exhaustion) and maximizing the reliability of fee bumping for L2 protocols in her <a href="https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/" rel="nofollow noreferrer">presentation</a> on &quot;Transaction Relay Policy for L2 Developers&quot; at Adopting Bitcoin 2021.</p>
<p>These perspectives thus far seem relatively aligned although may include slight differences in prioritization.</p>
<p>A stronger disagreement is with those who think policy is and should be used as a tool to restrict the propagation of certain use cases (ordinals, inscriptions etc) even when those transactions are consensus valid and have a high fee rate. In addition Luke Dashjr takes the view (on <a href="https://twitter.com/LukeDashjr/status/1749521346575360260?s=20" rel="nofollow noreferrer">X</a>) that:</p>
<blockquote>
<p>&quot;Transaction pinning&quot; AFAIK is a result of policy centralization efforts, not a real problem. The alternative is to encourage diverse policies, and at the technical level, to prepare multiple alternative transaction variants to ensure one being rejected won't be a problem.</p>
</blockquote>
<p>This alludes to a different disagreement on whether default (mempool) policy should be standardized across full node implementations to attempt to achieve its intended purposes. Full node operators are always free to change from the defaults (policy is not consensus) but standardization in this case would mean consistent defaults across different implementations.</p>

CC BY-SA 4.0
2024-02-07T11:51:59.710Z
2024-02-27T11:44:21.840Z
2024-02-27T11:44:21.840Z
Michael Folkson
<p>There are a couple of Stack Exchange posts on what (mempool) policy is, <a href="https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c">this</a> from Suhas Daftuar and <a href="https://bitcoin.stackexchange.com/questions/120269/what-is-mempool-policy">this</a> from Antoine Poinsot.</p>
<p>But what are the policy defaults in say Bitcoin Core trying to achieve and what should they be trying to achieve?</p>
<p>There seems to be some confusion on whether their sole purpose in the past was to restrict the propagation of certain types of high fee rate, consensus valid transactions and whether that purpose makes sense today when transactions can easily be submitted directly to a miner bypassing the P2P network.</p>

<bitcoin-core-development><mempool><p2p>
What should the intended purpose of (mempool) policy defaults in a full node implementation like Bitcoin Core be?
Michael Folkson
# What should the intended purpose of (mempool) policy defaults in a full node implementation like Bitcoin Core be?

(Asked by: username_0 on 2024-02-07)

There are a couple of Stack Exchange posts on what (mempool) policy is, [this](https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c) from Suhas Daftuar and [this](https://bitcoin.stackexchange.com/questions/120269/what-is-mempool-policy) from Antoine Poinsot.

But what are the policy defaults in say Bitcoin Core trying to achieve and what should they be trying to achieve?

There seems to be some confusion on whether their sole purpose in the past was to restrict the propagation of certain types of high fee rate, consensus valid transactions and whether that purpose makes sense today when transactions can easily be submitted directly to a miner bypassing the P2P network.

**Tags:** bitcoin-core-development, mempool, p2p


---

## 1 answers

### Answer by username_0 on 2024-02-07. Score: 2

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

instagibbs stated in his [policy zoo doc](https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8):

> There are N motivations for policy that I know of:
>
> Anti-DoS: Only “cheap” things to validate get flooded to the network
>
> Security: Certain types of transactions may mess up certain systems for no good reason
>
> Upgrade hooks: We leave some things “forbidden” such that if we find a use for them later we don’t “confiscate” funds by refusing to relay e.g., a spend or pre-signed transaction
>
> Pro-decentralization: Make it simple/cheap for miners to build blocks that pay well
>
> Paternalism: We want wallet authors to use the least amount of public resources while still accomplishing their end goals(as long as that goal isn’t “attack the network”!).
>
> Safe soft-fork process: Sometimes the only mechanism preventing an unupgraded miner from mining a block that would be considered invalid by upgraded miners (but valid by unupgraded miners) is policy discouragement.
>
> Let people pay fees to make transactions in an acceptable API
>
> All of these motivations obviously have to be weighed against the fact that bitcoiners want to make transactions, and miners want fees from those transactions. Ideally we make a mempool/relay system where both can live in relative harmony.

This corresponds to two of Suhas' intended purposes in his [Stack Exchange post](https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c/100319#100319).

> The purpose of policy checks is generally to (a) close off DoS vectors and (b) to make future consensus changes safer to deploy, by preventing relay of transactions that would violate such future consensus changes well in advance.

Gloria Zhao talks about the trade-off between protecting the bitcoind user from attacks (e.g. CPU exhaustion) and maximizing the reliability of fee bumping for L2 protocols in her [presentation](https://btctranscripts.com/adopting-bitcoin/2021/2021-11-16-gloria-zhao-transaction-relay-policy/) on "Transaction Relay Policy for L2 Developers" at Adopting Bitcoin 2021.

These perspectives thus far seem relatively aligned although may include slight differences in prioritization.

A stronger disagreement is with those who think policy is and should be used as a tool to restrict the propagation of certain use cases (ordinals, inscriptions etc) even when those transactions are consensus valid and have a high fee rate. In addition Luke Dashjr takes the view (on [X](https://twitter.com/LukeDashjr/status/1749521346575360260?s=20)) that:

> "Transaction pinning" AFAIK is a result of policy centralization efforts, not a real problem. The alternative is to encourage diverse policies, and at the technical level, to prepare multiple alternative transaction variants to ensure one being rejected won't be a problem.

This alludes to a different disagreement on whether default (mempool) policy should be standardized across full node implementations to attempt to achieve its intended purposes. Full node operators are always free to change from the defaults (policy is not consensus) but standardization in this case would mean consistent defaults across different implementations.


---

