Which ephemeral anchor script should lightning use?

The discussion opens by addressing an incident of accidental pinning observed in the wild, involving expired anchor outputs. This situation is described as not particularly noteworthy on its own, considering that anchor outputs for transactions already confirmed essentially present a minor opportunity for free satoshis to anyone interested. The real concern arises when transactions are structured in such a way that moving substantial funds depends also on claiming these small amounts, which is identified as a significant design flaw. The possibility of griefing, where a counterparty might exploit such vulnerabilities for profit, is highlighted as a notable risk. Even with precautions like keyed anchors, the counterparty is seen as more likely to engage in such behavior due to potential gains and their attentiveness to the transaction before it is mined, underscoring that completely eliminating this risk is impractical. Instead, the focus is shifted towards minimizing expected costs associated with these scenarios.

Further, the email discusses technical solutions and adjustments to mitigate such risks, including the implementation of the TRUC (Transaction Rate Uplift Coefficient), which aims to reduce costs by setting a limit on the ancestor count for transactions. The transition from a 4000vb to a 1000vb limit is mentioned, alongside suggestions for potentially introducing even lower limits as detailed in a Bitcoin Improvement Proposal and the rationale behind these changes. The email posits that while reducing the ancestor limit may not fully eliminate the risks, it could make attacks less economically viable for would-be griefers.

The economic incentives for mining pools to engage in such griefing practices are analyzed. The scenarios under which a mining pool might profit from executing high fee but low feerate transactions at the expense of users' transactions are outlined. However, it is argued that the likelihood of consistently profiting from such strategies seems low, given the potential for losses if the mempool clears and a competing pool mines the grieved transaction, thereby imposing extra fees on the attacker rather than the victim. Despite this, the potential for such tactics to become more common is acknowledged, suggesting a need for preventative measures.

In response to the discussed risks, the email proposes adopting a "replace by feerate" policy by some nodes or pools, especially for transactions that would otherwise remain at the top of the mempool. This approach, coupled with the concept of a clustered mempool, is presented as a means to more efficiently and effectively manage transaction prioritization and reduce the impact of griefing attempts, thereby enhancing overall network resilience and user experience.