V3 transaction policy for anti-pinning

This practice emerges from the scenario where low fee rate but large transactions (C1) are accepted over small transactions with higher fee rates (C2). The downside to replacing C1 with C2 is the vulnerability it creates for nodes, potentially exposing them to relay spam. To mitigate this issue, v3 introduces a mechanism where C1 transactions may be rejected outright, preventing the free relay problem and enabling high fee rate transactions like C2 to propagate through the network more effectively.

Despite not being a comprehensive solution to the pinning problem, v3 improvements offer significant benefits to the network by incrementally improving transaction relay policies. However, the constraints of v3, which limit transactions to one ancestor and one descendant, pose challenges, particularly for batch CPFP transactions—a technique used to speed up transaction confirmation—since it restricts complex related transactions in the mempool.

To adapt to these constraints, one could design protocols that have parent transactions with a single output available for immediate spending, ensuring any child transactions naturally conflict and fall under RBF (Replace-By-Fee) rules. Another possibility, although less practical, involves n-of-n multisig arrangements with transactions spending common outputs, which could theoretically comply with v3 policies.

The introduction of the ephemeral anchor (EA) rule offers additional flexibility, requiring that the EA output must be spent for the associated transaction to remain in the mempool. This condition ensures that children must spend and conflict with the EA output, invoking RBF rules. This added flexibility becomes especially advantageous for protocols like the Lightning Network, allowing the balance outputs of commitment transactions to be spent alongside the EA output, addressing what would otherwise be problematic scenarios.