<p>Because there must always be exactly one directly spendable output per party, in order to avoid one party to be able to &quot;exhaust&quot; the carve-out.</p>
<p>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.</p>
<p>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.</p>
<p>xref:</p>
<ul>
<li><a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html" rel="nofollow noreferrer">The carve-out proposal</a></li>
<li><a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001644.html" rel="nofollow noreferrer">The first mail (by Matt Corallo) expliciting the need of at most one directly spendable output for the carve-out to &quot;work&quot;</a>.</li>
</ul>

CC BY-SA 4.0
2020-09-03T19:36:40.793Z
Took me another 5 hours deep dive to understand everything that's going on here, but now I get it! Thank you for this quick and competent answer!
Dalit Sairio
CC BY-SA 4.0
2020-09-03T13:57:05.020Z
2020-09-03T23:57:16.820Z
2020-09-03T23:57:16.820Z
Antoine Poinsot
<p>Quote from <em><a href="https://bitcoinops.org/en/topics/anchor-outputs" rel="noreferrer">https://bitcoinops.org/en/topics/anchor-outputs</a></em>:</p>
<blockquote>
<p>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 <code>1 OP_CHECKSEQUENCEVERIFY (CSV)</code> condition that prevents them from being spent for at least one block.</p>
</blockquote>
<p>As far as I understand <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs" rel="noreferrer">https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#offered-htlc-outputs</a> , the addition of  <code>1 OP_CHECKSEQUENCEVERIFY (CSV)</code> is the only thing that changes within the output scripts of the Bitcoin transactions used by the Lightning protocol.</p>
<p>But why is this necessary? Why can't we just use CPFP without that relative delay of 1 block?</p>

<lightning-network><child-pays-for-parent><checksequenceverify>
Why do Anchor Outputs need to enforce an nSequence of 1?
Dalit Sairio
# Why do Anchor Outputs need to enforce an nSequence of 1?

(Asked by: username_0 on 2020-09-03)

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?

**Tags:** lightning-network, child-pays-for-parent, checksequenceverify


---

## 1 answers

### Answer by username_1 on 2020-09-03. Score: 5 | Accepted answer

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](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html)
* [The first mail (by Matt Corallo) expliciting the need of at most one directly spendable output for the carve-out to "work"](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001644.html).

> **Comments:**
> **username_0**: Took me another 5 hours deep dive to understand everything that's going on here, but now I get it! Thank you for this quick and competent answer!  

---

