Recovering a Core Lightning channel with hsm_secret but no current backup

[andersaamodt]

Hi,

I lost the server running my Core Lightning node. I still have the hsm_secret, but my emergency backup predates a channel I opened with ACINQ.

ACINQ suggested asking the Core Lightning team whether the channel can be resumed, or how to recover my outputs if they publish their commitment transaction.

I’ve recovered the internal channel database ID offline and verified that my secret derives the channel’s funding public key, but I don’t have the current channel database.

Is there a way to restore the channel using whatever state ACINQ still retains? If not, what information would you need from me or ACINQ to work out how to recover my funds after a force-close? What should I verify before asking them to close it, including whether any pending payments would need separate recovery?

Thanks!

[amartya1523]

Short version: the channel can't be resumed without the latest state, but the balance on your side is recoverable once ACINQ force-closes. Your hsm_secret plus the channel dbid is all you need for that part.

Why it can't be resumed: CLN has to know the latest commitment number and the per-commitment secrets to keep operating the channel. Restoring an older DB is dangerous (if you ever broadcast an old commitment you lose everything to a penalty tx), so don't try to "re-create" the channel from your emergency backup. Let ACINQ close it with their latest commitment.

Recovering your output after their unilateral close:

Any channel with ACINQ opened on a recent CLN will be an anchors channel (anchors are on by default since v24.02). That means your to_remote output on their commitment isn't a plain P2WPKH, it's a P2WSH:

<your_payment_basepoint> OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY

The key is static (no per-commitment tweak), so since you already know the dbid you can derive it directly:

lightning-hsmtool derivetoremote <acinq_node_id> <channel_dbid> /path/to/hsm_secret

(no commitment point argument, which tells it the channel uses static_remotekey). Note that guesstoremote won't match here: it compares against a P2WPKH hash, so it only works for pre-anchor channels.

To spend it you need a tx with nSequence >= 1 and the witness script above. The easiest way I know is a Bitcoin Core descriptor wallet, since that script is exactly the miniscript and_v(v:pk(K),older(1)). Convert the hex privkey to WIF and import wsh(and_v(v:pk(<WIF>),older(1))). Then compute the scriptPubKey/address and check it matches the output on ACINQ's close tx before you do anything else. Once their close tx has 1 confirmation you can sweep it like any other wallet output.

Before asking them to close, I'd verify:

• Your derived pubkey/script matches what ACINQ sees as your to_remote script for that channel. They can share the funding outpoint and the scriptPubKey of your output from their latest commitment.
• That there are no pending HTLCs on the channel. HTLC outputs use per-commitment keys and payment details that lived in your lost DB, so realistically they aren't recoverable this way. If there are any in flight, ask ACINQ to let them fail/settle first so everything lands in to_remote.
• That your old node is really dead and can never come back online with an old DB.

The FAQ section on "Database corruption / channel state lost" covers the same idea, but it predates anchors, so the P2WSH detail above is the part it's missing.