2+ Year Old Channel Closed But No Outputs Point At Any of My Wallet Addresses

[stealth2600]

Background

A mutual channel closure occurred between my node and another that had been opened for 2 years and 1 month. The initiator of the channel originally was the partner node, not mine and they also initiated the mutual closure. I attempted a CPFP fee bump using lncli wallet bumpfee, specifying the correct transaction id and output index since the transaction had been stuck in mempool for awhile. I then received the following error.

rpc error: code = Unknown desc = the passed output does not belong to the wallet

Upon further inspection of the transaction using lncli listchaintxn, I found that both output addresses for this transaction had the is_our_address parameter set to false. I am concerned that this has happened and I'm unsure if I will receive my funds whenever the transaction is finally committed to the block chain. Please see attached output from lncli listchaintxn illustrating the problem transaction.

Problem Transaction.txt

Your environment

• LND 0.16.4-beta
• Linux
• Bitcoin 25.0.0

Steps to reproduce

I'm not sure, it appears to have been caused by an old channel being closed.

Expected behaviour

I would have expected one of the outputs to point towards a wallet belonging to my node and the is_our_address parameter to be set to true.

Actual behaviour

All outputs of this transaction have the is_our_address parameter set to false and as a result I am unable to CPFP the transaction and I'm worried I won't receive the funds when the transaction is eventually committed to the blockchain.

[guggero]

Do you still see the channel in lncli pendingchannels or lncli listchannels? If yes, then this should automatically be closed as soon as the TX is in the mempool. It looks like there is a conflicting one (33d85c41c0b83fe8ebae9fa31a4e7665fbd514d439ab730e952fcaaed549d9cb) in the mempool with 1.1 sat/vByte. Given the current mempool situation, that should confirm in the next day or two (hopefully). So best case is you don't have to do anything.

The wallet doesn't recognize your output as belonging to it because is not derived directly from the seed. But you can use chantools sweepremoteclosed to accelerate the process if you don't want to wait. Just give it a high enough fee rate and it should confirm both the closing and the sweep TX.

Going to convert this into a discussion as this is just normal channel behavior.

[stealth2600]

Thanks for the response. Yes I do see the channel closure in lncli pendingchannels. I guess this is just a misunderstanding on my part as to how channels behave. Why would there be a conflicting transaction and how did you find it? I greatly appreciate all of the information and help.

[guggero]

The conflicting transaction might be your peer having force closed as well, but their TX survived in the mempool despite it being very full over the last couple of months. I decoded the raw transaction you posted, looked up what the input was and then found another spend on a block explorer.
Yes, I'm pretty sure this will resolve itself automatically in the coming hours/days.

[eliotcougar]

I have a similar situation. The channel in question was initiated by a remote party and closed several days ago mutually. The fee was set to 1.21 sat/vB. Because it's a STATIC_KEY channel with no anchors, I cannot bump the fee via CPFP. I suppose, only the initiating party can do that, but they decided to wait. Because the majority of the funds are on my end, not theirs, they have little incentive to push the transaction through, leaving my portion of the funds in limbo until that transaction confirms...

So, the question is this: Let's imagine the fees went high again, and there's no reason to believe the tx will confirm. What is the correct action in this situation? Do I attempt to force-close and wait 1-2 weeks to get my funds back? That may be less than the indeterminate amount of time the mutual close transaction can take. Who pays the force-close fee? I guess it's the remote party, right?

[stealth2600]

This is a great question, thanks for contributing to the discussion. Hopefully someone can instruct us both as to the best way to handle this scenario. My situation is exactly the same with regards to the transaction. Almost all of the funds are on my end as well and I don't even have a means to contact the node operator to request that they bump the fee. I'd be willing to reimburse them for the fee bump at this point as it will likely be cheaper than a force close. I'm sure someone will correct me if I'm wrong, but I'm pretty sure the initiator of the force closure pays the fee.

[guggero]

@eliotcougar why can't you CPFP the mutual close TX? That should be a normal address from your wallet. Did you try CPFPing the correct output?

The nodes shouldn't agree to a too-low fee rate, at least at the moment the channel is closed. But because both nodes can do CPFP in a co-op close case it shouldn't be a big issue.

[eliotcougar]

The transaction has finally confirmed today!!!

[eliotcougar]

@eliotcougar why can't you CPFP the mutual close TX? That should be a normal address from your wallet. Did you try CPFPing the correct output?

Because

"initiator": "INITIATOR_REMOTE",
"commitment_type": "STATIC_REMOTE_KEY"

There are no anchors for CPFP...

[eliotcougar]

That confuses me... Why is it a FC?.. What's special about local_txid?..
So, there's no way to bump the fee on my end?..

[guggero]

You can see it on the script types (one P2WPKH and one P2WSH), the channel flags (ChanStatusCommitBroadcasted|ChanStatusLocalCloseInitiator, meaning the commitment transaction was broadcast, which is the definition of a force close, and it was your node doing that) and the fact that there are two possible transactions that could go on-chain, the local one and the remote one. And since your TX you see in the mempool matches the local one, it just re-iterates the point that it was your node.

Correct, you don't have a way to bump, unfortunately. I think it's time to add an option to disallow non-anchor channels completely to avoid these kinds of situations, see #8075.

[eliotcougar]

It's not the first time I encounter issues with non-anchor channels... I was looking through config options and was surprised there is no way to disable these Legacy channels support... Looking forward to see what kind of rationale there is for keeping them always supported...

[guggero]

I don't think there is any rationale left anymore. For quite a while we couldn't disable them because the other implementations didn't support them. But with anchor channels now being implemented in most other LN software, I think it's time to add that option (and maybe even turn it on by default?).

[stealth2600]

I was discussing the issue with some folks from plebnet and the only means currently to prevent a non-anchor channel from being opened up with your node is through defining a rule with balance of satoshi (bos) inbound-channel-rules functionality. With the help of some plebs, I was able to setup a simple service that runs in the background with a series of channel open rules. This doesn't help @eliotcougar or I with our current dilemma, but it does prevent it from occurring again. I agree with @guggero, an option should be added to disable them moving forward, its quite frustrating to be in this situation.