You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[bug]: Restoring a node with SCB file after counterparty force closed channel long ago generates a pending_force_close channel that remains forever
#8366
Open
matheusd opened this issue
Jan 10, 2024
· 2 comments
Bob restores its node and applies SCB file during wallet init
Bob ends up with a pending_force_close channel with negative blocks_til_maturity that never resolves itself automatically.
How should such channels be handled?
Some options:
Leave channel there forever
Gonna have a channel on pending channels query forever
Node operator needs to always remember to ignore this channel
Restore again, but skip SCB
Could further interfere with other ongoing operations
More work for the node operator
(Optionally) filter when listing pending channels
Node operator will have to remember to specify the filter condition
If the filtering isn't optional, node operator may want to actually know about the channel
Add an RPC to remove this pending channel
Risky if user doesn't know what it's doing
Requires node operator intervention
Detect and remove such pending channels automatically
How to detect (which conditions apply here that don't conflict with other issues)?
Less work for node operator
May remove data before operator actually wants it gone
NOTE: Bob finds the on-chain funds correctly in this case, the issue is the extraneous entry in the pending_foce_close list.
Example itest that demonstrates issue
package itest
import (
"github.com/btcsuite/btcd/btcutil""github.com/davecgh/go-spew/spew""github.com/lightningnetwork/lnd/lnrpc""github.com/lightningnetwork/lnd/lntest"
)
functestRestoreWithSCBAfterLongForceClosed(ht*lntest.HarnessTest) {
chanAmt:=btcutil.Amount(100000)
alice:=ht.Alice// Create bob and track seed.password:= []byte("El Psy Kongroo")
bob, mnemonic, _:=ht.NewNodeWithSeed(
"dave", nil, password, false,
)
ht.EnsureConnected(alice, bob)
// Open alice <> bob channel.cp:=ht.OpenChannel(
alice, bob, lntest.OpenChannelParams{Amt: chanAmt},
)
// Advance channel state.constpaymentAmt=1000payReqs, _, _:=ht.CreatePayReqs(bob, paymentAmt, 1)
ht.CompletePaymentRequests(alice, payReqs)
// Save bob's backup.chanBackup:=bob.RPC.ExportAllChanBackups()
// Bob goes offline.ht.Shutdown(bob)
// Alice force-closes the channel while Bob is offline.ht.ForceCloseChannel(alice, cp)
// Mine a few blocks for good measure.ht.MineBlocks(64)
// Bob restores its node from seed, applying the SCB.backupSnapshot:=&lnrpc.ChanBackupSnapshot{
MultiChanBackup: chanBackup.MultiChanBackup,
}
bob2:=ht.RestoreNodeWithSeed("bob2", nil, password, mnemonic, "",
revocationWindow, backupSnapshot)
// Mine a few blocks for good measure.ht.MineBlocks(64)
// Channel was closed long ago, how to handle the pending force close// channel?resp:=bob2.RPC.PendingChannels()
ht.Logf(spew.Sdump(resp))
ht.AssertNumPendingForceClose(bob, 0) // This fails.
}
The text was updated successfully, but these errors were encountered:
So all the balance is on the side of Alice? I would expect Bob to mark the channel as fully resolved once it sees the force close transaction to confirm and no balance being on Bob's end. Are you sure it's not just a timing issue? E.g. if you wait a couple of hundred milliseconds after mining the blocks, does the channel not go away?
Or maybe it goes away once Alice successfully sweeps their time locked output?
Hmm, looks like it indeed depends on Bob's output being big enough to be fully recovered on the sweep. Going to make a a few different tests and see if I reproduce the issue I see in the field.
On the following scenario:
Bob ends up with a
pending_force_close
channel with negativeblocks_til_maturity
that never resolves itself automatically.How should such channels be handled?
Some options:
NOTE: Bob finds the on-chain funds correctly in this case, the issue is the extraneous entry in the pending_foce_close list.
Example itest that demonstrates issue
The text was updated successfully, but these errors were encountered: