3

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?

2

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:

| improve this answer | |
  • 1
    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 Sep 3 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.