Initially it’s value noting there appears to be some disagreement on this on the time of writing (February 2024).
instagibbs said in his coverage zoo doc:
There are N motivations for coverage that I do know of:
Anti-DoS: Solely “low-cost” issues to validate get flooded to the community
Safety: Sure forms of transactions might mess up sure techniques for no good motive
Improve hooks: We depart some issues “forbidden” such that if we discover a use for them later we don’t “confiscate” funds by refusing to relay e.g., a spend or pre-signed transaction
Professional-decentralization: Make it easy/low-cost for miners to construct blocks that pay effectively
Paternalism: We wish pockets authors to make use of the least quantity of public sources whereas nonetheless carrying out their finish targets(so long as that objective isn’t “assault the community”!).
Protected soft-fork course of: Typically the one mechanism stopping an unupgraded miner from mining a block that will be thought of invalid by upgraded miners (however legitimate by unupgraded miners) is coverage discouragement.
Let folks pay charges to make transactions in a suitable API
All of those motivations clearly must be weighed towards the truth that bitcoiners wish to make transactions, and miners need charges from these transactions. Ideally we make a mempool/relay system the place each can stay in relative concord.
This corresponds to 2 of Suhas’ supposed functions in his Stack Trade submit.
The aim of coverage checks is usually to (a) shut off DoS vectors and (b) to make future consensus adjustments safer to deploy, by stopping relay of transactions that will violate such future consensus adjustments effectively upfront.
Gloria Zhao talks in regards to the trade-off between defending the bitcoind person from assaults (e.g. CPU exhaustion) and maximizing the reliability of price bumping for L2 protocols in her presentation on “Transaction Relay Coverage for L2 Builders” at Adopting Bitcoin 2021.
These views up to now appear comparatively aligned though might embody slight variations in prioritization.
A stronger disagreement is with those that assume coverage is and must be used as a instrument to limit the propagation of sure use circumstances (ordinals, inscriptions and many others) even when these transactions are consensus legitimate and have a excessive price fee. As well as Luke Dashjr takes the view (on X) that:
“Transaction pinning” AFAIK is a results of coverage centralization efforts, not an actual drawback. The choice is to encourage various insurance policies, and on the technical degree, to organize a number of different transaction variants to make sure one being rejected will not be an issue.
This alludes to a special disagreement on whether or not default (mempool) coverage must be standardized throughout full node implementations to aim to realize its supposed functions. Full node operators are at all times free to vary from the defaults (coverage will not be consensus) however standardization on this case would imply constant defaults throughout totally different implementations.
