Core Lightning

This commit is a routine code cleanup: it introduces two helper functions, tal_arr_append and tal_arr_appendn, to replace repeated open-coded patterns of resizing a memory array and copying data into it. The change touches many files but does not fix any reported security bug. It adds extra memory-checking under Valgrind and a new unit test. There is no indication this patch is a security fix or that it addresses a known vulnerability.

This commit is a routine API enhancement for the `getroutes` command in Core Lightning. It adds extra, more explicit fields (such as incoming/outgoing node IDs and amounts) to each route hop so that callers can more easily pass the result to other APIs like `sendpay`. There is no indication of a security bug or fix.

This commit adds a privacy feature to Core Lightning's xpay plugin. When making a payment over a single non-blinded path, xpay can now add extra CLTV (timelock) blocks as a 'shadow' to make it harder for an intermediate node to tell that it is the final hop. This follows a BOLT 7 recommendation and mirrors behavior already present in the older 'pay' plugin. The change is purely additive and opt-in via a hidden developer flag.

This commit adds new code for creating and checking 'payer proofs' in Core Lightning, a feature used with BOLT 12 invoices. A payer proof lets someone who paid an invoice selectively reveal parts of it while keeping other parts hidden. The change is a new feature implementation, not a fix for a known bug or vulnerability. There is no evidence in the commit message or diff that this is a security patch or that it addresses any disclosed issue.

This commit adds a new command-line feature to a developer tool (bolt12-cli) that lets users decode and display a new type of BOLT 12 data structure called a 'payer proof.' It also makes a small, safe-looking fix to how text fields are printed so that trailing null bytes are not shown. There is no indication in the commit that this fixes a security vulnerability; it appears to be a normal feature addition.

This commit is a test-infrastructure change for Core Lightning's BOLT 12 payer proof implementation. It removes debug logging from the production merkle code and adds a new test program that prints canonical JSON test vectors. There is no change to security-sensitive runtime behavior, no bug fix, and no disclosed vulnerability.

This commit adds a new experimental JSON-RPC command called `createproof` to Core Lightning. It lets a user generate a cryptographically signed receipt (a 'payer proof') showing they successfully paid a BOLT12 invoice or offer. The change is a feature addition, not a fix for a known vulnerability. It exposes a new RPC that signs proof data using the node's keys, so the main security consideration is making sure only authorized callers can use it and that the proof data is signed correctly. The commit itself does not claim to fix any security issue, and there is no evidence of malicious intent or a disclosed vulnerability.

This commit is a code-quality refactor across many files. It changes the 'failure reason' string returned by BOLT11/BOLT12 decoding functions from a mutable 'char *' to a read-only 'const char *'. It also exposes a previously internal helper function and adds memory ownership fixes so callers don't accidentally use freed error strings. There is no direct evidence in the commit message or diff that this fixes an active security vulnerability, but it removes a class of potential memory-management mistakes and makes the API safer for future callers.

This commit refactors the code that builds BOLT12 merkle trees so it can handle 'omitted' fields via caller-supplied callbacks. It is a structural generalization, not a fix for a known bug or vulnerability. There is no direct evidence in the commit or supplied references that this change addresses a security issue.

This commit only adds a new automated test file and updates the build instructions to compile it. It does not change any production code, fix a bug, or alter behavior. The test exercises a feature called 'partial merkle tree support' used in BOLT12 invoices, but it is purely a test addition.

This commit adds support for decoding a new experimental BOLT12 format called a 'payer proof' in the Core Lightning node's decode command and related API bindings. It is a feature addition that extends existing decoding logic to recognize and return fields for payer proofs, such as the payment preimage, signature, and merkle proof hashes. There is no direct evidence in the commit that this fixes an active security vulnerability; it appears to be a protocol-support enhancement.

This commit fixes a simple math bug that caused the program to reserve up to twice as much temporary memory as needed when building a special data structure (a Merkle tree) used in BOLT 12 offers. The bug did not corrupt data or expose secrets; it only wasted memory. The patch removes an unnecessary '+1' in the allocation size calculation.

This commit adds a new data structure definition for 'payer proofs' in the BOLT12 (Bitcoin Lightning) wire protocol. It is purely a schema/import change: it adds a new TLV (Type-Length-Value) record type called payer_proof and lists its fields, plus includes a header file needed to compile it. There is no executable code, no parsing logic, no behavior change, and no indication of a bug or vulnerability.

This commit fixes a small display bug in a developer-only command-line tool (bolt12-cli). The tool decodes BOLT 12 offers, invoice requests, and invoices, but was failing to print the optional offer_metadata field. The fix simply adds three print statements so the field is shown when present. It does not change how Core Lightning nodes validate or process these messages, and there is no indication it fixes a security vulnerability.

This commit simply renames an internal helper function and makes it publicly available in a header file so other parts of the codebase can use it. There is no bug fix, behavior change, or security-sensitive logic alteration. It is a routine code-organization change.

This commit fixes a bug in Core Lightning's `decode` command for recurring payment offers. A previous code change split one offer field into two variants (compulsory and optional), but the `decode` output was not updated to match the new schema. The fix makes `decode` report a single `offer_recurrence` block with a new boolean flag indicating whether recurrence is compulsory. It is a correctness/API bug, not a direct funds-loss vulnerability, because it affects an experimental feature and would mainly cause decoding errors or misleading output rather than unauthorized payments.

This commit adds a missing data field, invreq_recurrence_cancel, to Core Lightning's decode command and related generated code. The field is part of the experimental BOLT12 recurring invoice request format and lets a payer signal that they want to cancel a recurring invoice. The change is mostly schema, RPC, gRPC, and test updates to expose and validate the new field. It is not a traditional security patch, but missing the field could have caused invoice-request decoding or validation to be incomplete for an experimental feature.

This commit only adds a new automated test to the Core Lightning project. It does not change any production code, fix a bug, or introduce a feature. The test checks whether a routing-reservation cleanup bug exists under heavy payment load, but the commit itself is purely a test addition with no patch.

This commit only changes a test file, increasing a timeout in an existing test by ten times. It does not modify any production code. There is no direct security fix or vulnerability being patched here; it appears to be a test reliability tweak to prevent flaky failures under slow or loaded test conditions.

This commit only adds two new automated tests that demonstrate an existing bug: the 'withdraw' command returns an unsigned raw transaction in its 'tx' field because an internal helper strips away signatures. The tests are marked as expected-to-fail, so the actual code flaw is not fixed here. A user relying on the returned transaction could receive a version that looks valid but would be rejected by the Bitcoin network because it lacks required witness data. The commit documents the regression but does not change the wallet logic itself.

This commit fixes a bug in Core Lightning's 'withdraw' command where the transaction shown to the user was returned without valid signatures or witness data, even though the actual network broadcast worked correctly. The returned 'tx' field looked like a real transaction but would be rejected if a user tried to broadcast it themselves. The fix ensures the returned transaction is fully signed and final.

This commit fixes a bug in Core Lightning where small change outputs on Bitcoin were being treated as too tiny to keep, causing them to be silently added to transaction fees instead of returned to the user. The fix lowers the threshold for P2TR/P2WPKH change outputs on Bitcoin from 546 satoshis to 330 satoshis, matching current Bitcoin network rules. Elements/Liquid still uses 546. Users could previously lose small change amounts as extra fees.

This commit only adds test data files (a seed corpus) for a fuzzing test named fuzz-open_channel. Fuzzing corpora are collections of example inputs used to exercise code during automated testing. No production code, protocol logic, or configuration is changed, and the commit message does not describe any security fix or vulnerability.

This commit only adds a new automated fuzz test for an existing function called fundee_channel(). It does not change the actual production code that handles incoming channel offers, so it cannot by itself introduce a security vulnerability or fix one. It is a testing improvement.

This commit only adds a new fuzz test file. Fuzz tests feed random data into program functions to check they behave correctly. There is no change to the actual wallet, network, or payment code that runs in production, so this commit does not introduce or fix a security vulnerability by itself.