Confed onchain tx showing not confed in listchaintxns

[GordianLN]

Background

All my channel opens are done from external wallet; most of those txns are not detected by lnd as confirmed, as reported by lncli listchaintxns. If I restart lnd, those transactions will disappear from lnd's history.
This doesn't appear to have happened for some channels, but recent opens look like they are all affected by this issue. I've been on 14.2 since the start of my adventure.
BTW, no fees are reported as well, should be possible to know them even if tx wasn't from lnd wallet, but I can fill that in manually on my accounting so it's much less of a pressing issue.

Your environment

• version of lnd 0.14.2
• which operating system (uname -a on *Nix) latest raspios 64bit
• version of btcd, bitcoind, or other backend 22
• any other relevant environment details //

Steps to reproduce

Open channel from external wallet, check lncli listchaintxns, observe how probably the txn is reported as having 0 confirmations even if it confed.

Expected behaviour

lnd correctly picks up the tx confirmations; ideally it also derives the fee

Actual behaviour

tx is reported as unconfirmed forever, and at lnd restart it disappears completely from the DB

[GordianLN]

I have been led to believe this might be due to who opened the channel; no certainty, but I'll surely keep track of it for new channels... yet the last two opens that I initiated in batch, and at least another open I initiated as my very first channel, have had this issue, while a balanced open I just received from the peer was correctly recorded as confirmed

[ziggie1984]

I also checked the lncli listchaintxnscommand and it reports all sweeps with a total_fee of 0, I did not check thoroughly all sweeps but this one here is an example:

 "tx_hash": "09d14521bcb7820b22e4c25fc4f600e008a3993e94a09153753e756cccf237ff",
  "amount": "776648",
  "num_confirmations": 6163,
  "block_hash": "00000000000000000008489a271853b1c5497abe6da18a0d95da44ff27d2928b",
  "block_height": 728383,
  "time_stamp": "1647882926",
  "total_fees": "0",
....

Normally I would argue that at least the chainfees need to be accounted for like 380 sats.

[Roasbeef]

A total fee of zero is shown when the wallet doesn't know about any of the inputs (so it can't compute the fee used). So that's expected behavior (it isn't tracking the complete UTXO set, only the inputs it knows about).

[Roasbeef]

Do you have logs at the time or channel open or start up logs?

[GordianLN]

Do you have logs at the time or channel open or start up logs?

Alas, I wouldn't be able to produce them, I'm sorry

[ziggie1984]

A total fee of zero is shown when the wallet doesn't know about any of the inputs (so it can't compute the fee used). So that's expected behavior (it isn't tracking the complete UTXO set, only the inputs it knows about).

In my case they were sweeps, after a channel-force-close, so LND selected inputs by itself, which means they knew about the inputs. But will look into the logging more thoroughly

[Crypt-iQ]

I'm fairly certain the missing txn's has to do with psbt channel funding

[Crypt-iQ]

I'm pretty sure the issue is that during the normal, internal funding flow, you're either:

• spending from a UTXO the wallet is already watching
  • this can happen any time the code calls NewAddress to request an address from the wallet
• spending to an output the wallet is watching
  • this can be the change address, called from NewAddress

In the externally funded case, neither of these things are happening (unless you construct a funding tx that pays to an address lnd knows about) so listchaintxns doesn't pick it up. This is reproducible by calling GetTransactions rpc in the external psbt funding itests.

It seems like the fix here would be calling NotifyReceived on a chain.Interface for the multi-sig output. The downside would be that anybody could send to this address and the wallet would pick it up and it would be unspendable.