lnd 0.21.4 stops opening Lightning channels of the legacy commitment type

Victoria Shinder03 October 2026, 13:002 min read

Lightning Labs released lnd 0.21.4-beta on 1 October, alongside 0.20.5-beta for the previous line. The release contains no database migrations, and its notes list one breaking change that node operators should understand before upgrading.

No more new legacy channels. lnd will no longer open or accept new channels that use the legacy commitment type, which was removed from the Lightning specification in 2024. The notes explain why it matters: in that format the to_remote output is tweaked, so if a node loses its data, it cannot recover the funds in such a channel on its own and needs the peer to supply the relevant commitment point. They also describe a gap that the change closes. An empty channel_type in an open_channel message asks for exactly this legacy type, and lnd used to accept it without any feature check, so a peer could obtain a legacy channel regardless of what either side had signalled. New channels now fall back to the static-remote-key commitment type instead, and the OpenChannel RPC rejects commitment_type LEGACY. Channels that already use the legacy type are not affected: they can still be used, force-closed and cooperatively closed.

Fixes worth knowing.

• A bug that could leave HTLCs pending while a channel moved between lifecycle states, potentially leading to unnecessary force closes and on-chain fees, is fixed.
• The HTLC forward interceptor now reconciles replays from the incoming link after a forward is resumed, so a replay is no longer treated as a second interception while the original outgoing HTLC is still live.
• When reconstruction of one AMP payment set fails, only that set's HTLCs are cancelled. Previously the whole invoice was cancelled, which broke reusable static AMP invoices.
• Peers now answer every valid inbound ping, as BOLT 1 requires; the existing flood limit remains the point at which a connection is torn down.
• BOLT 11 decoding now rejects invoices that carry more than one payment hash field. The notes point out that this is stricter than the current BOLT 11 text, which says to use the first one, so wallets that emit such invoices will see them refused.
• The migration to the native SQL graph store no longer fails on old channel records with empty features.

There is one addition for wallet builders: output leases in the WalletKit RPC can now stay active until the spending transaction reaches a chosen number of confirmations, instead of expiring on a timer.

What it means

The legacy-channel change is the one to check. Operators relying on peers or software that open channels with an empty channel_type will now get static-remote-key channels instead, which is the safer default for recovery after data loss. Wallet developers should also check that their invoices never carry two payment hashes.