[ad_1]
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.
[ad_2]
Source link
