Amber nodes are monitored by CommitWatch. Gray nodes are sampled from authenticated GitHub public commit search and may not represent complete contribution history.
This commit fixes the Nix package build for Core Lightning so that `nix build` works again. It is a build-system/documentation fix, not a security patch. There is no vulnerability being fixed here.
This commit only updates the Fedora installation instructions in the documentation. It changes command syntax, adds required build dependencies (openssl, openssl-devel, uv), bumps the example release tag, and switches the build instruction…
This commit adds a test that checks whether Core Lightning stops trying to replace (RBF) a penalty transaction once a replacement version has already been confirmed on the blockchain. The test documents a bug where the node would keep firi…
RBF loop does not terminate after replacement tx is confirmedUse of stale original_txid instead of current in-flight txid for confirmation checkIndefinite rebroadcast of on-chain penalty transaction
This fix resolves a bug where Core Lightning would keep trying to replace a transaction with a higher-fee version forever, even after the replacement had already been confirmed on the Bitcoin blockchain. The loop happened because the code …
CWE-835: Infinite LoopResource exhaustion via repeated on-chain transaction creationPotential fee loss / wallet bloat from perpetual RBF replacements
This commit only adds new automated tests for the bookkeeper feature, checking that it correctly records accounting events when Lightning channels are spliced in (adding funds) or spliced out (removing funds). It does not change any produc…
This commit only updates a single test file (tests/test_bookkeeper.py). It removes an experimental feature flag that is no longer needed, fixes Python style issues flagged by flake8, and replaces a hardcoded 5000-satoshi splice-out fee est…
This commit only adds a new pytest test case that reproduces a minor startup logging bug. Core Lightning was unnecessarily trying to re-broadcast already-confirmed channel funding transactions every time it restarted. Bitcoin rejected the …
Spurious rebroadcast of funding transactions on restartIncorrect channel depth check at startup due to DB load orderingRegression test added; no daemon code patched in this commit
This commit fixes a harmless but noisy bug in Core Lightning. On every restart, the node was trying to re-broadcast the funding transaction for channels that were already confirmed long ago. Bitcoin rejected these with a routine 'already k…
Spurious re-broadcast of funding transactions on node restartReliance on a field (channel->depth) that is uninitialized at the point of useRoutine bitcoind error -27 ('Transaction outputs already in utxo set') surfaced as UNUSUAL log
This commit updates the currency-rate plugin in Core Lightning. It adds a new optional 'source' argument to the `currencyrate` command so users can pick a specific price source, rounds displayed rates to three decimal places, and adds argu…
Input validation: argument-count limits added to three RPC methodsNew oracle helper validates source name, currency support, and cache TTL before returning a rateRounding change is a presentation-layer change, not a security fix
This commit only changes test code for the currencyrate plugin. It adds new tests for rounding behavior, selecting a specific rate source, and rejecting unknown sources or too many RPC arguments. There is no change to production code and n…
This commit adds a new optional 'source' argument to the currencyrate RPC command in Core Lightning. It lets users pick a specific exchange-rate source instead of getting the median across all sources. The change is purely a feature additi…
This commit only adds a README file for the currencyrate plugin. It contains documentation describing how to configure price sources and warning users that stopping the plugin can interrupt invoice creation. There are no code changes and n…
This commit only adds a new test case that demonstrates a known bug in Core Lightning's wallet handling. When a `withdraw` command fails because the Bitcoin node rejects the transaction broadcast (for example, the fee is too low), some fun…
Funds can be marked reserved after a failed broadcast, making them temporarily unavailable for spendingKnown bug is explicitly documented in test commentsNo production code fix is included in the commit
This commit only adds a new test case to the project's test suite. It does not change any production code. The test is marked as expected to fail (xfail) and is intended to reproduce a previously reported issue (#8863) about opening dual-f…
This commit simply deletes an old test from the test suite. It removes a pytest function that checked how the software handles opening a dual-funded channel when Bitcoin fee estimates are unavailable. There is no change to the actual softw…