explanation of 1 CSV rule on non-anchor outputs

[LLFourn]

I was just catching up on this topic. Thanks for the write up. In it there is this paragraph:

This ensures that there are only two outputs that can be used for CPFP: the newly added anchors. One of them can be used by us, the other by the remote participant. This ensures that whatever a malicious participant may do to prevent the commitment transaction from confirming in time, the honest participant always has an opportunity to leverage the CPFP carve-out rule to bump the fee at least once.

Why would an honest participant "not always have an opportunity to leverage CPFP carve-out rule" if there are more than two outputs that don't have a CSV?

It's mentioned in the mailing list https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html but it isn't explicitly stated why this is true.

[ariard]

Yes it's to avoid a malicious counterparty using first a HTLC output to reach limit_descendant_size with a chain of broad transactions and then occupying its dedicated carve-out output to fulfill the extra package space permitted by the carve-out rule (EXTRA_DESCENDANT_TX_SIZE_LIMIT) thus preventing a honest party to use its own output.

Merging them is problematic too as it would allow an attacker to reach package limits and thus prevent honest RBFs. As of today, if your package has reach ancestors/descendants limits, we only allow to replace one conflicted transaction part of this package due to DoS concerns. By chaining first, an attacker would block your capability to RBF.

[LLFourn]

Hmm. Ok so we have 1 tx with 3 outputs (commitment, and anchors). If commitment was not CSV'd then an attacker could create a transaction chain that spends commitment only but doesn't pay a good fee. Then they also spend the anchor output with a low fee also.

Bitcoin is going to enforce that there can be no more RBF spends from this transaction because 1) limit limit_descendant_size and 2) EXTRA_DESCENDANT_TX_SIZE_LIMIT has been taken up by the anchor output spend.

I think this could be explained better as we CSV all other outputs to make sure that a malicious party does not control more than one non-CSV'd output. That way an honest party with an anchor output will be able to use CPFP.

[ariard]

Yes there is other side-benefit of CSV'ing second-stage transaction, in case of successful pinning you can't spend both commitment/HTLC in same block and thus if an attacker delay your incoming claim for long enough, when commitment confirms you still have a chance to win the HTLC race.

[t-bast]

Exactly like @ariard said ;)

I'll modify this paragraph to explain this more thoroughly, thanks for the feedback, this is indeed one of the many subtleties!