Core Lightning

This is a routine code cleanup in Core Lightning's bitcoin-cli plugin. It pulls out duplicated code for running bitcoin-cli into a single shared helper function, with no intended behavior change. There is no indication this fixes or introduces a security vulnerability.

This commit is a routine internal code cleanup in Core Lightning's connection daemon. It replaces a hand-rolled memory buffer (a manually resized byte array with an offset) with a standard helper called membuf. There is no indication this fixes a security bug; it is described by the author as a more efficient and neater way to manage the outgoing encrypted message queue.

This change adjusts when Core Lightning's networking layer sends messages immediately versus batching them for up to a second. Previously, most messages were treated as non-urgent and could be delayed; now, only a small set of message types (HTLC updates and gossip) are batched, and everything else—including messages from plugins—is sent right away. The patch is framed as a performance/reliability improvement, but it removes a broad delay that could have masked timing-related bugs or made certain attacks easier by giving attackers predictable one-second windows to race against batched messages.

This change tweaks how Core Lightning's connection daemon decides when to actually send low-priority network messages to a peer. Previously it used TCP's Nagle algorithm to batch small messages; now it explicitly holds back non-urgent traffic for a short random timer (around half a second on average) and only flushes immediately for important messages such as connection setup, channel opens/closes, and payments. The goal is to reduce network noise from routine gossip while keeping time-sensitive traffic responsive. There is no direct evidence in the commit that this fixes a security vulnerability.

This change simplifies how Core Lightning's networking layer handles TCP packet batching. Previously, the code repeatedly turned a kernel feature called Nagle's algorithm on and off for each message depending on whether it was 'urgent.' Now it just leaves Nagle disabled all the time. The practical effect is lower latency for time-sensitive Lightning messages and less risk of inconsistent behavior across operating systems. It is not a fix for a known exploit, but it removes a fragile, platform-dependent mechanism that could have caused message delays or odd edge cases.

This change makes every encrypted network packet sent between Core Lightning peers the same fixed size (1460 bytes). When a real message is smaller than that, the software now stuffs the leftover space with a harmless dummy 'ping' message before sending. This is a privacy improvement: an outside observer watching the encrypted traffic can no longer guess what kind of message is being sent just by looking at packet lengths. It is not a fix for an active exploit, and it does not change what attackers can do.

This commit only changes how the project's automated test system is set up. It installs the Wireshark network-packet inspection tools and runs the test suite inside a special Linux group so tests can capture network packets. There is no change to the actual Core Lightning software that users run, and nothing in the commit suggests a security vulnerability or fix.

This change refactors how Core Lightning's connection daemon sends encrypted messages to peers. Previously, the daemon wrote entire encrypted messages in one go using io_write. Now it uses io_write_partial, which writes at most 1460 bytes at a time, tracking how much has been sent and continuing until the full message is transmitted. The stated goal is to create more uniform packet sizes on the wire. The patch itself is a defensive refactoring; there is no direct evidence in the commit or supplied references that it fixes a known exploitable vulnerability.

This is a routine internal code cleanup in Core Lightning's connection handling. It moves the logic for picking the next message to send into a new helper function, with no intended behavior change. There is no indication this fixes or introduces a security issue.

This commit simply deletes an outdated test from the test suite. The test used a '@' marker that was removed from the codebase in 2022, so it no longer works. There is no change to production code and no security issue is being fixed.

This is a small change to a developer testing tool (gossipwith) used to simulate Lightning network peers. It adjusts how the tool counts ping messages so that 'padding' pings—used only to keep packet sizes constant—do not reduce the limit on how many real messages the tool will process. The change is not in production node code and does not appear to fix a security vulnerability.

This commit is a code cleanup in Core Lightning's connection handling. It moves the developer-only 'dev-disconnect' test logic out of the main message-sending function into its own helper, without changing what the logic actually does. There is no indication this fixes or introduces a security issue.

This commit only adds a new test fixture and one test to the project's test suite. It lets developers capture network traffic during tests and check that TCP packet payloads stay a constant size. It does not change the actual Core Lightning software that users run, so it cannot introduce a security vulnerability or fix one in production code.

This commit fixes a flaky test in the Core Lightning test suite. The test was waiting until a node learned about another node's existence, but it actually needed to wait until it also learned the node's network address. No production code was changed, and there is no security issue.

This commit only adds a test case. It marks an existing emergency recovery test as expected to fail (xfail) and adds a single bookkeeping balance-listing call after recovery. There is no code fix or security change in the diff itself.

This commit fixes a crash in Core Lightning's bookkeeper plugin. After a user loses their main database and runs emergency recovery, then closes a channel, the bookkeeper plugin would hit an internal assertion and crash the whole node. The fix makes the plugin log a warning and continue running instead of crashing.

This is a small internal refactoring change in Core Lightning's gossip subsystem. It changes how 'dying' channel entries are loaded from the gossip store, switching from one temporary array to a callback that populates a persistent list. There is no indication this fixes a security bug or introduces a vulnerability; it appears to be code cleanup.

This commit changes how Core Lightning stores and tracks its internal gossip data file. It adds a unique identifier (UUID) to the front of the gossip store and includes that UUID in a 'store ended' marker so the node can tell when the file has been rewritten. The change is a normal data-format update, not a fix for an active security bug. There is one placeholder note in the code saying 'FIXME: real uuid!' which means the UUID is currently all zeros, but that is a completeness issue rather than an exploitable flaw.

This change makes the Lightning node's gossip database automatically shrink itself when it becomes bloated with old, deleted records. It also fixes a small bug where the wrong file descriptor was being closed during that cleanup process. There is no direct evidence this is a security fix, but uncontrolled file growth and incorrect descriptor handling can contribute to reliability or minor resource problems.

This commit adds a developer-only command to manually compact the gossip store file used by Core Lightning. It is a testing and diagnostic feature, not a normal user function. The command is gated behind the 'developer' build mode and does not change how regular users run the software. There is no indication in the commit that this fixes a security bug or introduces a security vulnerability.

This is a small bug-fix in a downgrade helper tool. Previously, the tool only deleted an incompatible gossip data file when the database actually needed changes. Now it deletes that file even if the database is already compatible, preventing a scenario where downgrading leaves behind a gossip file that the older version cannot read. It is a correctness fix, not an exploitable security vulnerability.

This commit adds internal bookkeeping counters that track how many gossip records are currently active versus how many have been deleted in Core Lightning's network map. It does not change any security behavior, fix a bug, or alter how data is validated. It simply provides statistics so that a future compaction routine can decide when to clean up the map.

This commit changes a developer-only test tool so the fake channel IDs it creates are less predictable. The goal is to speed up test startup and prevent CI timeouts, not to fix a security bug. No production code is affected.

This commit improves a developer-only diagnostic tool (dump-gossipstore) so it prints the channel or node identifier alongside raw gossip messages. It is not a security fix and does not change any network-facing or wallet code. The only functional change is richer debug output.

This patch fixes a bug in Core Lightning's gossip daemon where, after compacting the network graph store, the list of 'dying' channels was not reset and the code that repopulates it was not hooked up. This could cause the node to lose track of channels that are being closed, potentially leading to incorrect routing decisions or stale channel state. The fix clears the old list and provides a callback so dying channels are reloaded from the newly compacted store.