Which ephemeral anchor script should lightning use?

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.

    For example, every Saturday night, Bob automatically takes his node offline for 30 minutes to perform a full filesystem backup and software update. His counterparty, Mallory, learns about his predictable downtime from her logs and causes the maximum amount of trimmed HTLC value to be forwarded through his node to her node shortly before his next downtime. She then force closes the channel with the keyed anchor paying for next-block confirmation, which at that time is less than its full value, allowing her to profit.

  • 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.

    Long reorgs create all sorts of other problems, so I’m not claiming that this is a strong criticism, but it does seem better to me that out-of-band fee payment can’t reduce the chance that a commitment transaction will re-mined in a reorg.