Core Lightning v26.04 RC2 Ships Message Padding, Closes Privacy Gap

On April 2, 2026, Core Lightning tagged v26.04rc2 to GitHub, and the changelog contained a feature that had been missing from the Lightning Network's toolbox: peer messages are now padded to uniform length by default. This is not a small tweak. For five years, every packet flowing through the Lightning Network has leaked metadata through its size alone — even when the content is encrypted, an adversary watching the wire could infer routing hops, estimate payment amounts, and map node activity by observing which peers send messages to which, and how often. CLN v26.04 RC2 stops that leak. No other Lightning implementation ships this by default yet.

Core Lightning is one of four major Lightning implementations — alongside LND (Blockstream/Lightning Labs), Eclair (ACINQ), and LDK (Square Crypto). CLN has been in production mainnet use since early 2018 and is written in C, favoring efficiency and a modular, plugin-first architecture. The broader Lightning Network, as of March 2026, operates 17,000 public nodes, 40,000 public payment channels, and holds approximately 4,900 BTC in announced channel capacity. That is real value flowing through these pipes, and for the first time in CLN's history, the operator of that infrastructure can deploy it against a known class of adversaries — the ones sitting on the wire.

RC2 delivers four concrete changes. First: message padding. When a peer sends a message to CLN, the implementation now pads it to a standard length before transmission, removing the information content of packet size. This is pure privacy infrastructure — it does not change routing, fees, or payment completion; it simply makes it harder for a network-layer observer to triangulate who is talking to whom and what they are doing. Second: the `splicein` and `spliceout` commands, which moved from experimental to first-class user-facing operations in RC1, are now backed by improved UX in RC2, including cross-splice capability — you can now specify a second channel ID as the destination of a `spliceout`, allowing funds to move from one channel directly to another without an on-chain bounce. Third: binaries are approximately 20% smaller, reducing the deployment footprint for embedded nodes and IoT devices running CLN (the latter being a stated design priority). Fourth: reproducible builds are now confirmed on Fedora targets, meaning operators can verify that their binary matches the source code without needing to trust the release infrastructure. On April 6, Bitcoin Core 28.4 arrived as a stable maintenance release — the underlying node software that CLN depends on to anchor its channel operations on-chain. The timing is not coincidence; infrastructure upgrades move in tandem.

The message-padding feature emerged from a well-understood vulnerability in Lightning's privacy model. The protocol has always encrypted payment content between routing nodes, so the plaintext of a transaction is hidden. But packet size is metadata, and metadata is not encrypted. If you observe that a peer receives a 247-byte message, you know something about the transaction flowing through that peer — perhaps it is a multi-hop route, or a payment to a specific address length class. An observer on the wire, or a peer in the network, can use packet-size patterns over time to build a map of routing behavior. CLN v26.04 RC2 neutralizes this by padding all peer messages to the same length, trading a small amount of bandwidth for the information security of making all messages look identical. The cost is minimal; the gain is architectural. This is the kind of privacy hardening that shows up in mature, security-conscious infrastructure — not because the vulnerability is flashy, but because it is real and systematic.

The splice feature represents a different kind of unlock. Splicing — the ability to resize a Lightning channel without closing it — has been experimental in CLN since v23.08 and has been a long-standing request from operators who manage liquidity across dozens or hundreds of channels. Until now, if you wanted to add funds to a channel, you had to close it, wait for on-chain confirmation, and open a new channel; if you wanted to remove funds, the same friction applied. This is fine for a static network, but it is a scaling bottleneck for operators running merchant hubs, routing nodes, or multi-hop infrastructure. The `splicein` and `spliceout` commands collapse this workflow into two simple operations. `splicein` funds a channel from your wallet in a single atomic transaction. `spliceout` removes funds from a channel in a single atomic transaction. For a node operator managing 50 channels, this is the difference between one command per liquidity adjustment and a five-step manual process. The user-facing impact is profound; the technical impact is precision engineering of an existing mechanism. RC1 introduced this; RC2 refines the UX and adds cross-splice support, letting operators move funds between channels directly. This is the kind of feature that sits dormant in a release candidate for two weeks while developers stress-test it in production and then ships as a stable standard.

Here is what this actually means, stripped of the release-note framing. Core Lightning is making two simultaneous moves: it is hardening the privacy posture of the Lightning Network against a known class of adversaries, and it is removing the operational friction that has kept channel management in the hands of technical operators only. Message padding addresses a problem that has existed since day one — one that LND, Eclair, and LDK have not solved yet, and that no BOLT (Basis of Lightning Technology) specification mandates. This is CLN saying: we will absorb the small bandwidth cost to make our network layer defensible. Splicing commands address a problem that has kept Lightning adoption shallow — liquidity management by non-technical operators. Together, these changes are not headlines; they are the kind of infrastructure work that separates systems that stay niche from systems that scale to production. CLN is shipping them together in the same release candidate cycle. The question is whether the broader Lightning ecosystem adopts the message-padding approach as a standard. If LND, Eclair, and LDK do not follow, CLN operators gain a modest privacy edge but the network as a whole does not achieve the same defense. If they do follow, the default behavior of Lightning becomes harder to surveil at scale. We expect LDK to move faster than the others — it is implemented in Rust and designed for modularity — and we expect a BOLT spec proposal to follow within 60 days of v26.04 stable release. Until then, CLN has a privacy advantage; after adoption, the network has one.

Watch four things. First: the final v26.04 stable release, expected within 2–4 weeks of RC2. The timing matters because we are currently in an ultra-low-fee environment — Mempool.space reports 1 sat/vB for 1-hour confirmation as of April 6 — meaning the cost to anchor splice transactions on-chain is near-minimal. This window closes fast when fee pressure returns; node operators who want to test or execute splices should do so while the fee environment permits. Second: cross-implementation interoperability testing of `splicein`/`spliceout`. Splicing support across LND, Eclair, and LDK is currently uneven; if the new commands do not cross-operate cleanly, they remain a CLN feature, not a network upgrade. Third: adoption of message padding as a BOLT specification. If the four major implementations agree to ship message padding by default within six months, the network-layer privacy story changes materially. If CLN carries this alone, it is a niche hardening, not a standard. Fourth: the Bitcoin Core 28.4 upgrade cycle among node operators. CLN requires a compatible local or remote bitcoind instance; operators planning to upgrade Core to 28.4 should test CLN compatibility in a staging environment before rolling out both simultaneously.