[bug]: coin selection uses "RBF"ed inputs

[C-Otto]

See #5959 for a very related issue.

Background

An unconfirmed output that should not be used because it is double-spent as part of RBF is used as an input for a funding transaction (when allowing unconfirmed inputs).

My gut feeling is that this issue also affects sweep transactions, i.e. (important?) sweep transactions that are invalid because of a double spent input.

Your environment

• version of lnd: 0.16.4
• which operating system (uname -a on *Nix): Linux server 6.1.0-11-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 GNU/Linux
• version of btcd, bitcoind, or other backend: bitcoind v25

Steps to reproduce

Have an unconfirmed transaction that has been "replaced by fee" (RBF), i.e. another transaction spending the same output also exists. Open a channel using "--min_confs 0".

Expected behaviour

The replacing version of the same transaction (paying a higher fee) should be regarded.

Actual behaviour

The replaced transaction is used, possibly even in conjunction with the replacement transaction.

[C-Otto]

Actually, I think this is a duplicate of #5959. Feel free to close. Sorry.

[Roasbeef]

So coin selection can't actually know what the transaction that spends an input looks like (nor what all the prior transactions look like, if replacements exist). A user could have spent it via the PSBT APIs, or manually otherwise. The issue here only arises when spending unconfirmed change.

[C-Otto]

I agree, lnd can't know what users do outside of lnd. However, I believe that lnd should be able to skip inputs that are the result of internal "RBF"ing. And yes, it helps to wait for confirmation.

[nayuta-ueno]

In my case, when I restarted lnd v0.15.4, some INPUT txs of funding transactions(zero-conf channel) changed to UTXOs (they appeared in the output of listunspent --min_confs=1).
Since I ran "openchannel" without noticing this, I created several double-spending transactions even though I didn't set the --min_confs option.

[C-Otto]

@nayuta-ueno I suggest you create a new issue for this (with further information). My gut feeling is that zero-conf channels have issues unrelated to the issue I described here.

[yyforyongyu]

fixed by #8545