# Which ephemeral anchor script should lightning use?

**URL:** <https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412>\
**Category:** Protocol Design\
**Tags:** lightning\
**Created:** [January 31, 2025, 3:47pm UTC](https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412 "2025-01-31T15:47:17Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![harding](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/harding/32/925_2.png) [@harding](https://delvingbitcoin.org/u/harding)\
**Post date:** [February 4, 2025, 2:11pm UTC](https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412/4 "2025-02-04T14:11:45Z")

</div>

Notwithstanding @instagibbs’s comments about a dynamic approach, option 1 (P2A) seems much safer to me:

- _Theft of trimmed HTLC value:_ options 2, 3, and 4 allow a counterparty to receive trimmed HTLC value if their force close is uncontested while it is in the mempool. Average time in the mempool is easily reduced to 10 minutes by paying a next-block fee, and it may be possible for your counterparty to make good guesses about when your node will be offline for ~10 minutes.

- _Reduction in reorg safety:_ a counterparty that works with a miner can pay the full value of a keyed anchor to their wallet, leaving both the commitment transaction and the CPFP transaction as zero fee in a block. If there’s a natural reorg, no rational miner will include those zero-fee transactions in their reorg blocks, reopening a channel that previously seemed closed. If the reorg is long enough, it may become possible to steal value from regular HTLCs in the reopened channel.

---

_[View the full topic](https://delvingbitcoin.org/t/which-ephemeral-anchor-script-should-lightning-use/1412)._