2

There are a couple of Stack Exchange posts on what (mempool) policy is, this from Suhas Daftuar and this 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.

1 Answer 1

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:

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.

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 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) 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.