Bumping on-chain deposit uses CPFP (after it already confirmed)

[maflcko]

There seems to be a race when an on-chain deposit confirms and the user at the same time bumps it. Ideally, for bumping RBF is used, so that only one version of the transaction is confirmed (and the others are "conflicting", and impossible to confirm).

However, currently it seems, at least in the case where the deposit is already confirmed and the channel utxo is already updated on-chain, that a CPFP transaction is created.

Using CPFP is problematic for many reasons:

• It is more expensive and uses more block space than RBF, because the user has to pay for the overhead of another full 1-in-1-out transaction for each bump. (In my example, I was able to create 2 transactions with one input and one output)
• It is worse for privacy, compared to RBF, because each bump is recorded on-chain forever.
• It is possible to uselessly bump a transaction that already confirmed.

I couldn't find a downside to RBF, unless I am missing something?

[maflcko]

Ok, I guess the downside of using RBF would be that all channel copies would need to be updated at the same time and it would be unclear which balance to display to the user.

[t-bast]

The main reason we have to use CPFP instead of RBF here is 0-conf. We cannot RBF a splice transaction after a payment has been made on the spliced channel, because that would invalidate the corresponding commitment transaction which creates an opportunity to steal funds.

You don't really need to bump the splice transaction in the first place: even though it's unconfirmed, the spliced-in funds can be used immediately over lightning (because we use a variation of swap-in-potentiam to protect against double-spends). It can stay unconfirmed for a while, or you can simply wait for the next on-chain deposit to implicitly bump that transaction.

[maflcko]

You don't really need to bump ...

Right, higher priority probably seems to be working on taproot-ranged-descriptor support for the swap-in potentiam, so closing for now. :)