Does `option_simple_close` depend on CPFP carve out ?

[tankyleo]

• Mallory gets from Bob a signature on her mutual close transaction with a moderately low feerate (She has an output on her mutual close transaction that she can spend).
• She broadcasts her mutual close transaction before Bob broadcasts his own mutual close.
• She broadcasts a huge child on her mutual close that maxes out the package size limit, also moderately low feerate, but high absolute fee before Bob broadcasts his mutual close.
• Bob cannot force close because the commitment transaction does not pay a higher absolute fee than Mallory's package.
• Bob is not able to pay the absolute fee required to replace Mallory's package with his own mutual close.
• So his only choice is to rely on CPFP carve out to CPFP Mallory's package via his own output on Mallory's mutual close transaction.

[Roasbeef]

Mallory's goal here is just delaying both of them from receiving their funds on-chain?

If Bob has a balance in the channel, then he has an output he can spend on the coop close transaction. He can then use that output to fee bump if needed.

Bob is not able to pay the absolute fee required to replace Mallory's package with his own mutual close.

Because Mallory doesn't respond, or because he doesn't have enough funds in the channel to pay out of?

What do you mean by depend here? It is the case that CPFP can be used as a fall back if RBF isn't possible (your peer doesn't support the new protocol, doesn't respond, invalid replacement, etc). The existing (legacy) coop close flow can only rely on CPFP usage to bump the fee of the close transaction.

[tankyleo]

Mallory's goal here is just delaying both of them from receiving their funds on-chain?

Yes this is the result.

If Bob has a balance in the channel, then he has an output he can spend on the coop close transaction. He can then use that output to fee bump if needed.

Agreed.

Because Mallory doesn't respond, or because he doesn't have enough funds in the channel to pay out of?

The second, in other words, because he does not have enough funds in the channel to pay the much higher absolute fee required to RBF.

What do you mean by depend here? It is the case that CPFP can be used as a fall back if RBF isn't possible.

That the CPFP carve out policy is the only reason Bob can CPFP Mallory's mutual close and get some of his funds back (EDIT: in the setup above).

Thanks for the input.

[tnull]

That the CPFP carve out policy is the only reason Bob can CPFP Mallory's mutual close and get some of his funds back.

I guess if we agree with this conclusion, the next question would be if option_simple_close transactions would need to be v3 in order to be considered safe against such an attack?

Note that client nodes might not have mempool visibility to even detect the pin. Hence, they would need to start 'blindly' CPFP'ing the counterparty's close, IIUC?

[t-bast]

This is the same discussion we had for splice transactions, where the same pinning may apply. This doesn't allow stealing funds, it's "only" a griefing attack, which costs the attacker (they need to have a channel with the attacked node and they need funds to be on the attacked node's side, which means that paid routing fees to get in that state). It is annoying, but not to the point where it's worth making closing txs v3 (which doesn't benefit from the anonymity set of v2 txs). Cluster mempool something something to eventually fix this.

[TheBlueMatt]

It is annoying, but not to the point where it's worth making closing txs v3 (which doesn't benefit from the anonymity set of v2 txs).

Why not? The anonymity set will presumably increase over time (at least marginally), and the whole point of v3 coop close is to remove the issues we have with coop close that can lead to stuck funds. The ability of a counterparty to prevent you from getting access to your funds is a pretty major issue, even if not one that we have yet fully solved in the normal lightning flow (but TRUC commitment txn will get us close!).

Cluster mempool something something to eventually fix this.

Cluster mempool doesn't solve naive pinning-by-weight attacks. It cannot because its fundamentally an incentives question, deciding whether to accept such replacements depends on your percent of hashrate and how likely you are to mine a block now vs later plus your estimate of where fees are going to trend.

[t-bast]

But there is no point in using v3 for mutual close transactions if the force-close transactions don't use v3 as well, right? The attacker would simply refuse to sign your v3 mutual close, forcing you to force-close with a v2 commit tx, which they can pin just like they would pin a v2 mutual close tx? And a v3 package cannot evict a v2 package, can it?

It seems to me that we probably want to make mutual mutual close transactions v3 when the commit txs are using v3, but there is no point in changing it for v2 commit txs right now.

[TheBlueMatt]

Indeed, there's not much reason to change it now for the existing channels, but for TRUC channels we definitely want to have v3 close txn. IMO we should do it for current channels as well to avoid accidental pinning, but its definitely not as important.

[tnull]

Indeed, there's not much reason to change it now for the existing channels, but for TRUC channels we definitely want to have v3 close txn. IMO we should do it for current channels as well to avoid accidental pinning, but its definitely not as important.

Just want to note this approach was briefly discussed and confirmed in yesterday's spec meeting (cf #1228 (comment))

[Roasbeef]

Acknowledging that this is a griefing vector, does TRUC actually even help here?

IIUC, Alice wants to delay Bob from receiving his funds on chain as she thinks he's icky. She then makes some big package to try to pin this coop close transaction. There're actually no funds at risk here, and Alice gains nothing by doing this, and will just pay a bunch of chain fees assuming the entire package confirms.

From the TRUC BIP:

An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant

IIUC, this means that if Alice adds an unconfirmed spend "before" Bob does, and then goes offline, that Bob can't use CPFP to attempt to increase the fee of the coop close transaction. So then Bob is still prevented from using CPFP to increase the fee rate, no?

[morehouse]

IIUC, Alice wants to delay Bob from receiving his funds on chain as she thinks he's icky. She then makes some big package to try to pin this coop close transaction. There're actually no funds at risk here, and Alice gains nothing by doing this, and will just pay a bunch of chain fees assuming the entire package confirms.

Funds cannot be stolen but can be locked up until the mempool empties enough to confirm the co-op close. This could be an especially effective way to liquidity grief LSPs -- attacker opens several large channels with the LSP, pushes funds to the LSP's side, then broadcasts and pins all the co-op closes for those channels (jointly to save on fees). If enough funds are locked up for long enough, the LSP may lose considerable revenue due to the lack of available liquidity.

From the TRUC BIP:

An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant

IIUC, this means that if Alice adds an unconfirmed spend "before" Bob does, and then goes offline, that Bob can't use CPFP to attempt to increase the fee of the coop close transaction. So then Bob is still prevented from using CPFP to increase the fee rate, no?

There's sibling eviction for TRUC transactions, so Bob's CPFP can replace Alice's if it pays more fees.

[Roasbeef]

There's sibling eviction for TRUC transactions

Ahh, looks like they added this on later (?), as it isn't explicitly mentioned in the specification section of the TRUC BIP. Perhaps the BIP should be updated to mention sibling eviction explicitly.