Which ephemeral anchor script should lightning use?

This is due to their ability to rely on their commitment package overriding the counterparty's when fees are increased sufficiently. This simplification not only reduces the complexity of code but is particularly advantageous for mobile applications, leading to a recommendation to disregard Options 3 and 4. These options offer the capability to CPFP the remote commitment, a feature unlikely to be widely adopted in TRUC channels.

The discourse then transitions into evaluating the remaining options, taking into consideration two primary issues: fee griefing and dust theft. A proposition is made to adopt Option 2, utilizing the same anchor script currently in use, alongside implementing changes suggested by @instagibbs concerning the handling of dust HTLCs. This approach aims to mitigate both identified issues effectively.

Delving deeper, the analysis contrasts unkeyed anchors against single-participant keyed anchors. It highlights that while unkeyed anchors present long-term security against dust theft attacks, they remain vulnerable to fee griefing through conflicting anchor spends. Conversely, single-participant keyed anchors restrict the capacity for fee griefing and replacement cycling solely to the channel counterparty. However, this option initially leaves room for dust HTLC theft by the counterparty.

An innovative alternative is proposed, building on the single-participant keyed anchor model without inflating the anchor value. This involves increasing the keyed anchor's value up to the dust limit through dust HTLCs, beyond which any additional dust HTLCs would augment the commitment fees instead. This model curtails the possibility of dust theft by ensuring any excess goes towards miners as commitment fees, thus presenting a balanced solution to the outlined concerns.

Further contemplation reveals that current strategies against replacement cycling, such as rebroadcasting and aggressive fee bumping, adequately deter potential attacks, making the threat of additional exposure from unkeyed anchors manageable. However, keyed anchors are favored for their reduced vulnerability to griefing tactics observable in lightning force closures within the mempool.

To circumvent dust HTLC theft while avoiding UTXO bloat, the discussion suggests the integration of an anyone-can-spend path with a CSV delay to non-ephemeral anchors, similar to existing anchor channels. The conversation concludes with a technical specification for transitioning to a P2WSH anchor script once an anchor output reaches a valuation threshold, although maintaining the current anchor script is advised for simplicity until further optimizations are explored in taproot TRUC channels.