Core Lightning

This commit is mostly a cleanup: it removes old asynchronous code from the bitcoin-cli plugin after it was converted to run commands one at a time (synchronously). The only functional bug fix is adding a missing `close(from)` call, which stops a file descriptor leak when running bitcoin-cli. There is no obvious new security vulnerability introduced by the change.

This change rewrites how Core Lightning asks Bitcoin for fee estimates, switching from an asynchronous (multi-step callback) style to a simpler synchronous style. It also adds a shared helper for reporting bad JSON responses from bitcoin-cli and fixes a typo in a log message ('32 bites' to '32 bits'). The rewrite does not obviously add or remove a vulnerability, but it changes timing and error-handling behavior in a security-sensitive area (fee estimation), so it warrants careful review.

This change alters how Core Lightning's bitcoin backend plugin reacts when the connected Bitcoin node cannot find a requested block by height. Previously, only one specific error code (8) was treated as 'block not found,' while any other failure caused Core Lightning to report a hard error and stop. Now, any non-zero failure from the 'getblockhash' command is treated as 'not found.' This makes the plugin more tolerant of Bitcoin node behavior differences, but could mask real backend problems such as network errors, authentication failures, or node crashes by silently treating them as missing blocks.

This commit adds a new internal helper function that runs the bitcoin-cli command synchronously (waiting for it to finish before continuing). It is marked UNNEEDED, meaning it is not currently used anywhere. The change appears to be a pure code-structure refactor with no active security behavior introduced.

This commit changes how Core Lightning submits raw Bitcoin transactions to the local bitcoin node. Previously it was done in the background (asynchronous); now it is done inline (synchronous) and returns the result directly. The change is a refactor that makes error handling more explicit and helps functional tests observe failures. There is no direct evidence in the commit that this fixes an exploitable security bug.

This commit changes how a Core Lightning plugin asks its connected Bitcoin node about transaction outputs. It switches one internal call from asynchronous to synchronous execution and adds more detailed error messages. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a code-quality and robustness improvement.

This commit is a simple code cleanup: it replaces three hard-coded numbers in the bitcoin-cli plugin with named constants. The actual behavior of the program does not change at all. There is no security fix here.

This commit only adds new automated tests to the Core Lightning project. It does not change any production code, so it cannot introduce a security vulnerability by itself. The tests exercise an existing retry mechanism in the bitcoin backend plugin (bcli) when a pruned Bitcoin node temporarily cannot return a block. One test documents that Core Lightning will shut down (fatal error) if the retry path runs out of time. That behavior is already present in the code; the test merely records it.

This commit changes how the bitcoin-cli plugin answers the 'getchaininfo' request. Previously it started an asynchronous background job and later returned the result. Now it calls bitcoin-cli directly and waits for the answer before responding. The change removes the 'UNNEEDED' marker from the synchronous helper functions, because they are now used, and marks the old asynchronous result handler as no longer needed. On its own this is a routine internal refactor; it does not obviously fix a security bug, but it does remove one asynchronous path where race conditions or state confusion could occur.

This commit refactors how Core Lightning handles replies from its internal Bitcoin plugin (bcli). Previously, if the plugin reported an error, the main daemon might try to read a non-existent 'result' field and produce a confusing 'bad result' message. The new helper explicitly checks for an 'error' field first and extracts the real error message. It also makes several callbacks parse the 'result' object directly instead of expecting it to be wrapped in a top-level '{result:{...}}' structure. This is primarily a robustness/logging improvement; it does not by itself fix a known exploitable vulnerability, but it removes a class of error-handling gaps that could hide or misreport plugin failures.

This commit only changes test files. It updates pytest test cases to match new behavior after a code refactor made the lightning node crash instead of retry when it gets invalid responses from the connected Bitcoin node. There is no change to production code, so it does not introduce or fix a security vulnerability by itself.

This commit rewrites one internal plugin function so it calls the Bitcoin backend in a straightforward, step-by-step (synchronous) style instead of a chain of callbacks. It also renames an internal error helper so it can print 'command failed' when the backend returns a non-zero exit code, not only 'bad JSON'. The change is mostly a refactor; it does not obviously fix or introduce a security vulnerability on its own.

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 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 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 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 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 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 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 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 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 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 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 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.