It hinges on the concept that transaction creators can engage bots to create transactions that are beneficial for miners, thereby avoiding scenarios where miners would have to run additional software to maximize their earnings. This is especially pertinent where systems automatically generate ephemeral anchors, such as with lightning networks, which necessitate the integration of transaction-creating bots into existing software.

A nuanced aspect of this discussion involves the handling of trimmed Hash Time-Locked Contracts (HTLCs). There exists a potential for perverse incentives where a counter-party might leverage circular routing to fund unilateral closures rather than attempting HTLC resolution. One proposed solution to this issue is to donate the trimmed value through an OP_RETURN burn, ultimately resulting in a more favorable incentive structure, albeit with an increased waste in the average case. However, concerns have been raised about the possibility of adversaries inflating the required size for ephemeral anchor spends due to anti-Denial-of-Service rules like bip125 rule3, effectively creating risks even when pure burns would suffice for block inclusion.

When it comes to managing dust HTLCs in Lightning Network transactions, two primary methods have been identified. The first keeps the protocol unchanged but increases the fees associated with commitment transactions by the amount of the dust HTLC. The second adds the dust HTLC amount to the ephemeral anchor output, maintaining constant commitment transaction fees. While the former could lead to excessive on-chain fees, the latter simplifies the Lightning protocol but introduces the risk of miners preferring to claim the entire value of the ephemeral anchor output for themselves, thus presenting MEV opportunities. As such, the current preference leans towards the second option, despite its potential inefficiencies.

In discussing the creation of non-trivial-value ephemeral anchors, questions arise regarding the necessity and potential consequences of incorporating code to handle these scenarios. The discourse extends into the realms of BIP discussions, specifically addressing the challenges presented by ephemeral anchor funds and their management to prevent malfeasance. A notable GitHub discussion led by user @ariard provided insight into these issues and suggested solutions to mitigate them, including changes to RBF rules to combat front-running and theft by counter-parties in smart contracts. The adoption of a new rule, akin to one proposed in Bitcoin Pull Request 2898, could be instrumental in safeguarding against opportunistic claims on ephemeral anchor values and reducing the likelihood of MEV situations. This approach aligns with broader goals to create a secure and equitable transaction landscape for all participating entities.