[bug]: open channel fails - tx not broadcast, remote node with stuck pending channel #8327
Comments
mrfelton
changed the title
|
I find this log abnormal, As this is a channel opening and nothing should be resolved by contract court. Could you do a search over |
that is what the logs above are. Those show all references to that channel point and the pending channel id |
|
The above log means this line was executed, lnd/contractcourt/chain_arbitrator.go Line 442 in ab8fb2c which is a logging generated from the method lnd/contractcourt/channel_arbitrator.go Lines 1277 to 1280 in ab8fb2c there's another occurrence in Then the only place is in Line 2793 in ab8fb2c and this can only happen via RPC |
|
EDIT: The channel was opened using a PSBT flow. And looking at our code it is possible that abandon channel could have been called as we do call this in the event that we detected that a channel opening attempt failed. Will need to do some more digging in our application logs to determine the exact sequence of events. |
|
A little more digging in our application logs shows that indeed it does look related to the double spend. It appears that the channel opening attempt failed due the double spend - I see Then, as part of an automated cleanup it seems we have called abandon channel. We do this because we have found that if we do not abandon the failed channel opening attempt, it will remain stuck in a pending state forever. |
|
Do you use the psbt flow in combination with the |
|
Yes, It's done using the WalletKit |
|
Yes either that, or try not to use unconfirmed outputs for now because I think it has to do with the sweeping of the anchor output which is RBFed by a third party |
|
Ok, interesting. We do currently set |
|
After updating to not spend unconfirmed outputs we no longer see this problem.
Is there an existing issue that tracks the root problem here? |
|
Closing in favor of #7602 (identified as the root problem). |
Hi, we have a reoccurring scenario in which channel open attempts fail - no channel opening transaction is broadcast, and the channel does not exist in the node's channel database after the opening attempt, but the remote node does still have a record of the channel in its db and has it stuck in a pending open state.
I'd like to understand how/why this happens, and what could be done to prevent it.
Here are some logs related to one of these events (we have had at least three of them in the last couple of weeks).
After this, there seems to be no record of the channel or it's funding transaction on the node or in the mempool.
However, the channel shows up on the remote node as pending open:
{ "channel": { "remote_node_pub": "027cd974e47086291bb8a5b0160a889c738f2712a703b8ea939985fd16f3aae67e", "channel_point": "dbe8a0325a9ddb75489e446b01b9f96d019809171c2fda44374ad40b0da7cd2e:0", "capacity": "56746331", "local_balance": "0", "remote_balance": "56742861", "local_chan_reserve_sat": "567463", "remote_chan_reserve_sat": "567463", "initiator": "INITIATOR_REMOTE", "commitment_type": "ANCHORS", "num_forwarding_packages": "0", "chan_status_flags": "", "private": false, "memo": "" }, "commit_fee": "2810", "commit_weight": "772", "fee_per_kw": "2500", "funding_expiry_blocks": 529 }After restarting the node some time later, some log messages about this channel do show up during the restart, although there is no change with the channel state (or lack of it).
I believe the remote node will eventually forget about this channel after some time (~2 weeks from the opening attempt), however it's problematic for us as it leaves the remote node in a state where it thinks there is a pending channel, which counts towards
maxpendingchannelsand can result in the remote node rejecting additional channel opens from the node.It seems that the channel opening transaction will never get broadcast - so is this channel safe to abandon on the remote side in order to clear it from their pending channels list?
Why could this have happened in the first place? Thanks!
Is the
transaction rejected: output already spentlog entry related? I can't tell because I can't finds anything in that log message, or in theRemoved invalid transaction: (*wire.MsgTx)(0xc022e77080)log message that proceeds it that correlates with the channel open request, other than the fact that it occurred right during the middle of the channel open attempt at the same timestamp.If it is related to the doublespend, how can we prevent channel opening attempts from double spends that cause failures or detect this and self heal more gracefully?
The text was updated successfully, but these errors were encountered: