Why do Anchor Outputs need to enforce an nSequence of 1?

Question

Quote from https://bitcoinops.org/en/topics/anchor-outputs:

As of this writing, the most recent versions of the design add two outputs to the commitment transaction—one for each LN party—and require all other outputs in the commitment transaction to have their scripts encumbered by a 1 OP_CHECKSEQUENCEVERIFY (CSV) condition that prevents them from being spent for at least one block.

As far as I understand https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs , the addition of 1 OP_CHECKSEQUENCEVERIFY (CSV) is the only thing that changes within the output scripts of the Bitcoin transactions used by the Lightning protocol.

But why is this necessary? Why can't we just use CPFP without that relative delay of 1 block?

Answer 1

Because there must always be exactly one directly spendable output per party, in order to avoid one party to be able to "exhaust" the carve-out.

With two CPFP-ble outputs, one party could both create a chain of descendants transactions on the first outputs so that it meets the standard mempool limits and then trigger the carve-out mechanism using its own second output.

This way, the HTLC transactions are not included in the mempool and cannot be used to either create a long chain of descendants, or used as a carve-out transaction.

xref:

• The carve-out proposal
• The first mail (by Matt Corallo) expliciting the need of at most one directly spendable output for the carve-out to "work".