Modular C implementation of the Lightning Network protocol and node stack.
Every captured commit receives deterministic security triage and a separate communication-quality score. Security candidates and broader second-pass signals receive full-patch Ollama analysis.
Aug 5 → Feb 61049 seen37 candidatesCompleteFeb 6 → Jun 6579 seen10 candidatesCompleteJun 6 → Jul 678 seen1 candidatesCompleteJul 6 → Aug 5147 seen16 candidatesCompleteMessage quality measures whether a commit identifies its scope, purpose, rationale, testing, and supporting references. It does not change the security-severity score.
Public Git author strings; identities are not independently verified.
Last scanned 45 minutes ago
This commit simply adds a new person's PGP public-key fingerprint to the list of trusted release signers in two documentation files. It does not change any code, fix any bug, or alter any security behavior of the software itself.
41278b4eby jaonoctus+2−02 filesThis is a tiny internal fix to make a bookkeeping migration produce stable event ordering. It changes the timestamp used when creating historical 'deposit' records during a one-time database migration, so the records sort consistently with…
498e5086by daywalker90+2−01 fileThis commit is a documentation-only cleanup of the JSON-RPC command help files. It corrects which numeric error codes are listed for each command so the published schemas match what the software actually returns. No program logic, validati…
d1b6963bby daywalker90+204−1224 filesThis commit fixes a bug where a setting that controls whether unexpected transaction signatures are allowed was not initialized when the channel daemon starts. If a peer sent such signatures before the channel was fully ready, the program …
c09c4520by Erick Cestari+1−01 fileThis commit fixes the project's internal nightly code-coverage CI workflow. It changes how test coverage files are collected, ensures the same LLVM compiler version is used to generate and merge coverage data, and uploads a Codecov-compati…
5685c9a3by cdecker+12−211 fileThis commit is a large cleanup of Core Lightning's API schemas, generated RPC bindings, and related plugin code. The stated goal is to make the documented 'required' fields match what the C code actually always produces or expects. In prac…
ddbd2963by daywalker90+1786−173950 filesThis commit only updates documentation. It adds error code 313 to the documented error lists for several Core Lightning commands (fundpsbt, utxopsbt, txprepare, multiwithdraw, and upgradewallet). The error code already existed in the code …
a34b9758by Peter Neuroth+30−86 filesThis commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-sig…
8e495707by Peter Neuroth+5−21 fileThis commit updates Core Lightning's release documentation to tell users and release managers to run gpg --verify with both the signature file and the manifest file named explicitly. The old one-argument form can silently succeed even if t…
2dee8699by Peter Neuroth+9−62 filesThis commit is a routine update to the Rust dependency lock file (Cargo.lock), bumping many third-party libraries to newer patch or minor versions. The commit message gives no security reason for the update, and no verified references link…
c1551c55by daywalker90+298−2761 fileThis commit fixes a stack-overflow risk in Core Lightning's JSON parser. Before the fix, an attacker could send a valid JSON-RPC message containing thousands of nested brackets or braces. The parser's own helper functions used recursion fo…
83f92e4bby Níckolas Goline+90−22 filesThis commit only fixes typos and comment style. It changes two C-style comments from // to /* */ and corrects a grammar error in a documentation comment ('element' to 'elements'). There are no code behavior changes, no bug fixes, and no se…
273d7f02by w3lld1+3−32 filesThis change fixes a test-infrastructure bug in Core Lightning's Python testing helpers. When running tests against a PostgreSQL database, very long test names could be silently shortened by PostgreSQL, causing different test runs or nodes …
c4fe4cbaby Peter Neuroth+59−12 filesThis fix prevents Core Lightning from trying to use freshly created bitcoins (immature coinbase rewards) as emergency funds for fee-bump transactions. Such a transaction would be invalid under Bitcoin's rules and would be rejected by the n…
34883ff7by cdecker+5−12 filesThis commit fixes a bug in Core Lightning's askrene plugin that could prevent a node from restarting. When a saved routing layer contained a node bias with a description, the plugin accidentally freed the description's memory while using i…
4681177dby Vincenzo Palazzo+2−32 filesThis commit only fixes a test case so it actually exercises the intended code path. It does not change any production code, so it cannot introduce or fix a real-world security vulnerability by itself. The test change is a reproducer for a …
0f3f67a0by Vincenzo Palazzo+3−21 fileThis commit fixes a bug in Core Lightning's experimental dual-funded channel feature. When another node tried to open a channel, Core Lightning was not checking whether the proposed transaction fees were reasonable. A peer could request a …
ba08356fby cdecker+140−04 filesThis commit adds regression tests for three related bugs where wildly wrong Bitcoin transaction feerates could enter Core Lightning. In the worst case, a malicious or broken fee source could make the node think a feerate was zero (due to a…
65bdbc47by cdecker+137−02 filesThis update fixes a crash bug in Core Lightning. When the software tried to list details of a channel opening in progress, it could crash if a stored fee rate was extremely large or zero. The crash happened because the code used an interna…
d67c4936by cdecker+72−227 filesThis commit fixes a bug where Core Lightning nodes could get stuck in a crash loop. If a node had previously stored an extremely high or zero fee rate for an in-progress channel funding operation (a 'splice' or dual-funded channel RBF), a …
f057c692by cdecker+34−01 fileExpand any commit for its author, full message, clarity score, changed files, triage signals, analysis, and source link.
a9c99fe2 · Jul 18, 2026 · 2 filesLow 32pyln-proto: temporarily switch to coincurve-cp314-fix
Using `uv.sources` / `uv.index` does not work when publishing to pypi.
Instead i forked coincurve master, published all the wheels as coincurve-cp314-fix
v22 with fixes to make it work on python 3.14
Changelog-None
This change swaps the project's Python cryptography dependency from the well-known 'coincurve' package to a temporary fork called 'coincurve-cp314-fix' published by an individual contributor (daywalker90). The stated reason is to fix Python 3.14 compatibility while still being publishable to PyPI. Because the new package is a fork maintained outside the original project, users now depend on a less-trusted supply chain. There is no direct evidence of malicious code in the commit, but the change increases supply-chain risk.
40a74a7f · Jul 18, 2026 · 1 fileInformational 12renepay: add test to check for wrong CLTV computation
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only adds a new test case to the Core Lightning test suite. The test is marked as expected to fail (xfail) and checks whether the renepay plugin computes the CLTV (a timeout value used in Lightning payments) correctly. It does not change any production code, fix a bug, or introduce a vulnerability. It is a regression test that documents a suspected miscalculation.
9181505e · Jul 18, 2026 · 4 filesModerate 60renepay: fix CLTV value for the first hop
Changelog-Fixed: renepay: fix the computation of the CLTV for the first hop, it was double counting the current blockheight leading to too 900k blocks into the future.
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit fixes a bug in Core Lightning's renepay plugin where the time-lock expiry (CLTV) for the first hop of a payment was incorrectly calculated by adding the current block height twice. This caused HTLCs to be created with expiry values roughly 900,000 blocks too far in the future. Such far-future expiries could make payments fail or behave unexpectedly, and in edge cases could affect fund safety by making HTLCs resolve very slowly.
d4a960ba · Jul 17, 2026 · 1 fileInformational 15tests: fix flaky reckless tests by waiting for the canned github server
The canned_github_server fixture Popens a Flask server and never
waits for it to start listening; the git repository setup between the
Popen and the yield usually gives it enough time. Under CI load it
can lose that race: a valgrind-shard failure shows test_search's
first reckless invocation getting connection refused within a second
of the test starting, while Flask's "Running on http://127.0.0.1:..."
banner only appears in the log after the test had already failed.
Wait for the port to accept connections before yielding, and fail
loudly if the server process dies instead of coming up.
Changelog-None
This commit fixes a flaky automated test, not a security bug. The test harness previously started a fake GitHub server and sometimes tried to use it before it was ready, causing random test failures. The patch simply waits for the server to be ready before continuing. There is no vulnerability in production code and no user impact.
8405796b · Jul 17, 2026 · 14 filesLow 34msggen: new rust types for `sat` and `sat_or_all`
Also stop serializing amounts as string with msat suffix in cln-rpc
and serialize them as a raw number instead, like CLN does it
Changelog-None
This commit changes how the Core Lightning (CLN) Rust RPC and gRPC libraries represent and serialize amounts. It introduces separate types for satoshi-denominated amounts (AmountSat) versus millisatoshi-denominated amounts (Amount), and changes serialization from strings like "10000msat" to raw numbers like 10000. This is a breaking API and wire-format change for generated Rust/gRPC clients, but it is intentional cleanup rather than a clear security fix. There is no vendor statement that this resolves a security issue, and no independent researcher is credited.
7def3af0 · Jul 16, 2026 · 3 filesModerate 59lightningd: reject a channel that reuses an existing funding outpoint
A v1 channel_id is derived solely from the funding outpoint, so two
channels funded by the same outpoint would share a channel_id. When a
peer completes a second funding using an outpoint we already have a
channel for, refuse it and drop the connection instead of committing a
second channel with a colliding channel_id.
Add find_channel_by_funding_outpoint() to look up an existing channel by
its funding outpoint.
This change prevents a peer from accidentally or maliciously opening a second Lightning channel using the exact same Bitcoin transaction output as an existing channel. Because channel IDs are derived from that funding output, reusing it would create two channels with the same ID, which could confuse the node and potentially lead to incorrect routing or state handling. The fix detects the duplicate and disconnects the peer before the second channel is committed.
c7a013c8 · Jul 16, 2026 · 1 fileLow 42connectd: handle an already-connected subd gracefully
peer_connect_subd asserted that the subd had no connection yet. Replace
that assertion with defensive handling: if a connection is already
attached for this channel_id, keep it and close the incoming fd. This
avoids aborting connectd in the unexpected case where a second fd
arrives for a subd that already has one.
This change fixes a crash in the part of Core Lightning that handles peer connections. Previously, if the same internal connection was unexpectedly set up twice, the program would abort with an assertion failure. Now it logs a debug message and closes the duplicate connection instead. This makes the node more stable against unusual or possibly malicious connection patterns, but the patch is defensive and does not by itself prove an attacker could reliably trigger the crash.
3e0f48e1 · Jul 16, 2026 · 1 fileModerate 61tests: test RBF stops after closed tx is confirmed
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 firing replacement attempts indefinitely because it looked up the wrong (stale) transaction ID and thought the original was still unconfirmed. The commit itself only adds a regression test, not the fix, so the actual vulnerability is in the pre-existing code being tested.
15a66cbc · Jul 16, 2026 · 1 fileModerate 59chaintopology: fix RBF loop that never stops after replacement tx confirms
After consider_onchain_rebroadcast() creates a higher-fee replacement,
rebroadcast_txs() calls refresh() which updates otx->tx in-place, but
the confirmation guard still queries the original otx->txid (the map key):
if (wallet_transaction_height(topo->ld->wallet, &otx->txid))
continue;
Because the original tx was never mined (only the replacement was),
wallet_transaction_height always returns 0 and the RBF loop fires on
every subsequent block forever, even after the channel is fully resolved.
Fix: compute cur_txid from the current otx->tx before the guard. This
naturally reflects any replacement made by a prior refresh() call, so
wallet_transaction_height finds the confirmed txid and skips the entry.
otx->txid (the hash-map key) is intentionally left unchanged: mutating
the key in-place while the entry lives in the map would corrupt the table.
Changelog-Fixed: chaintopology: stop the on-chain RBF rebroadcast loop once a fee-bumped replacement transaction confirms; previously the loop kept firing on every new block forever.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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 checked the old transaction ID instead of the current one. This wasted resources, created unnecessary transactions, and could bloat the wallet or leak funds through repeated fees.
f5965b3a · Jul 15, 2026 · 1 fileInformational 15tests: test bookkeeper correctly accounts for splice in/out
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 production code, so it cannot introduce a security vulnerability or directly fix one in the shipped software.
906663a0 · Jul 15, 2026 · 1 fileInformational 15tests: fixing flake8 + fixed fees in spliceout
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 estimate with a dynamic fee calculation based on the node's feerate. There is no change to production code, no security fix, and no vulnerability being patched.
58863ab6 · Jul 15, 2026 · 1 fileInformational 15docs: updated Arch linux source installation instructions
Also removed python plugin instructions, they can not be generalized and this repo no
longer has any python plugins that need extra dependencies in production.
Python plugins from the plugins repo have their own documentation.
Changelog-None
This commit only updates the Arch Linux installation instructions in the project's documentation. It replaces the older Poetry-based Python setup with the newer 'uv' tool, adds some system dependencies, and removes a section about Python plugins. There are no code changes and no security implications.
92fbf33d · Jul 15, 2026 · 1 fileInformational 18build-release: fix VERSION build-arg and add --no-push for the docker target
Pass the computed VERSION as a build-arg, mirroring the docker-release workflow. Without it the container's VERSION is set-but-empty, `VERSION ?=` in the Makefile won't overwrite it, the git-describe fallback never runs, and `make install-program` fails with "git is required for generating version information".
Also add --no-push, so a release captain can do a full test build without publishing elementsproject/lightningd:$VERSION and :latest (the target always runs `docker buildx build --push`, since multi-arch images cannot be --load'ed into the classic docker store). The build only populates the builder's cache; a subsequent run without the flag pushes from cache quickly.
Co-Authored-By: Claude <claude@users.noreply.github.com>
This is a build-script bug fix, not a security vulnerability. The release script for Core Lightning was failing to pass the version number into Docker builds, which caused the build to fail with a confusing git-related error. The patch also adds a --no-push option so release builders can test the Docker build without accidentally publishing images. There is no attacker-controlled behavior or code execution risk.
eb42ca93 · Jul 15, 2026 · 2 filesInformational 16pyln-proto: use coincurve 21 for python <=3.13 and add self-compiled wheels for python 3.14
coincurve 20 is broken for all python versions since it now pulls in a transient dependency that turned
a warning into an error:
```
× Failed to build `coincurve==20.0.0`
├─▶ The build backend returned an error
╰─▶ Call to `hatchling.build.build_wheel` failed (exit status: 7)
[stderr]
ERROR: Use build.verbose instead of cmake.verbose for scikit-build-core >= 0.10
hint: This usually indicates a problem with the package or the build environment.
help: `coincurve` (v20.0.0) was included because `cln-meta-project` (v0.1.0) depends on `pyln-proto` (v26.6.2) which depends on `coincurve`
```
coincurve 21 does not have this issue but it does have another issue with python 3.14:
```
Resolved 1 package in 289ms
× Failed to build `coincurve==21.0.0`
├─▶ The build backend returned an error
╰─▶ Call to `hatchling.build.build_wheel` failed (exit status: 1)
[stderr]
Traceback (most recent call last):
File "<string>", line 11, in <module>
wheel_filename = backend.build_wheel("/home/user/.cache/uv/builds-v0/.tmpfcwWrQ", {}, None)
File "/home/user/.cache/uv/builds-v0/.tmpNmyA8G/lib/python3.14/site-packages/hatchling/build.py", line 58, in build_wheel
return os.path.basename(next(builder.build(directory=wheel_directory, versions=["standard"])))
~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/user/.cache/uv/builds-v0/.tmpNmyA8G/lib/python3.14/site-packages/hatchling/builders/plugin/interface.py", line 149, in build
build_hook.initialize(version, build_data)
~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
File "/home/user/.cache/uv/sdists-v9/pypi/coincurve/21.0.0/sA4L50tQMHeL37XJdHnME/src/hatch_build.py", line 34, in initialize
raise RuntimeError(message)
RuntimeError: Expected exactly one LICENSE file in cffi distribution, got 0
hint: This usually indicates a problem with the package or the build environment.
```
coincurve for python 3.14 is fixed upstream but there is no release yet, so we use self-compiled wheels just for python 3.14
Changelog-None
This change updates how the project installs a cryptographic helper library called coincurve. The old pinned version was failing to build, so the team switched to a newer official version for most Python releases and, only for Python 3.14, to pre-built wheels hosted by an individual contributor (daywalker90) while waiting for an official fix. The main risk is that Python 3.14 users now trust a third-party package index and compiled binaries instead of the official PyPI release.
cfb877a3 · Jul 15, 2026 · 1 fileInformational 17Improve reliability of wait_and_check_bitcoind
Changelog-Fixed: Fixed spurious bitcoind startup failures by retrying bitcoin-cli -rpcwait checks when RPC briefly fails.
This change is a reliability fix for how Core Lightning waits for the Bitcoin node (bitcoind) to be ready during startup. It replaces one long 30-second wait with 30 shorter 1-second retries to avoid cases where the connection check would hang even though bitcoind was already available. There is no direct security vulnerability being patched; it is a bug-fix for startup failures.
12790264 · Jul 14, 2026 · 1 fileInformational 15CODEOWNERS: remove @devrandom
without write access CODEOWNER does not work
Changelog-None
This commit simply removes a GitHub user from the CODEOWNERS file for one file. CODEOWNERS controls who is automatically asked to review changes. The user was removed because they no longer have write access, which is required for CODEOWNERS to work. There is no code change and no security issue in the commit itself.
f40be192 · Jul 14, 2026 · 1 fileLow 47ecdh_hsmd: ensure HSM fd is blocking on setup
On macOS under load, socketpair fds sent via SCM_RIGHTS can have
O_NONBLOCK set (from the sender's io_new_conn call in hsmd's
pass_client_hsmfd). This causes wire_sync_read to return NULL
with EAGAIN, killing connectd or channeld with "No hsmd ECDH response".
The fix mirrors the "Don't trust subd to set it blocking" pattern
already used in lightningd/subd.c:read_fds(): explicitly call
io_fd_block(hsm_fd, true) in ecdh_hsmd_setup.
Changelog-Fixed: connectd: fix intermittent "No hsmd ECDH response" crash on macOS under load.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit fixes a bug where a special internal communication channel (file descriptor) used by Core Lightning could accidentally be left in non-blocking mode on macOS under heavy load. When that happened, a part of the program expecting a blocking read would get an unexpected 'try again' error and crash with 'No hsmd ECDH response.' The fix explicitly forces the channel to blocking mode when it is set up, matching a safety pattern already used elsewhere in the codebase. It is a reliability fix rather than a security vulnerability in the usual attacker-vs-system sense.
678ff47d · Jul 14, 2026 · 3 filesLow 25crates: update dependencies and upgrade quick-xml, tower-http, and tokio-tungstenite
```
cargo update
Updating crates.io index
Locking 62 packages to latest Rust 1.85.0 compatible versions
Updating anyhow v1.0.102 -> v1.0.103
Updating arc-swap v1.9.1 -> v1.9.2
Updating arrayvec v0.7.6 -> v0.7.8
Updating base58ck v0.1.100 -> v0.1.101
Updating bitcoin v0.32.100 -> v0.32.101
Adding bitcoin-consensus-encoding v1.0.0
Adding bitcoin-internals v0.5.0
Updating bitcoin-io v0.1.100 -> v0.1.101
Updating bitcoin-units v0.1.100 -> v0.1.101
Updating bitcoin_hashes v0.14.100 -> v0.14.101
Adding block-buffer v0.12.1
Updating bytes v1.11.1 -> v1.12.1
Updating cc v1.2.64 -> v1.2.67
Updating chacha20 v0.10.0 -> v0.10.1
Adding const-oid v0.10.2
Adding crypto-common v0.2.2
Adding defmt v1.1.1
Adding defmt-macros v1.1.1
Adding defmt-parser v1.0.0
Adding digest v0.11.3
Updating env_filter v1.0.1 -> v2.0.0
Updating env_logger v0.11.10 -> v0.11.11
Updating fs-err v3.3.0 -> v3.3.1
Updating getrandom v0.4.2 -> v0.4.3
Adding hex-conservative v0.3.2
Adding hybrid-array v0.4.13
Removing id-arena v2.3.0
Updating jiff v0.2.28 -> v0.2.32
Updating jiff-static v0.2.28 -> v0.2.32
Updating js-sys v0.3.102 -> v0.3.103
Removing leb128fmt v0.1.0
Updating lightning v0.1.8 -> v0.1.11
Updating lightning-invoice v0.33.2 -> v0.33.3
Updating lightning-types v0.2.0 -> v0.2.1
Updating log v0.4.32 -> v0.4.33
Updating memchr v2.8.2 -> v2.8.3
Updating num-bigint v0.4.6 -> v0.4.8
Updating possiblyrandom v0.2.0 -> v0.2.1
Updating quote v1.0.45 -> v1.0.46
Removing rand v0.9.4
Removing rand v0.10.1
Adding rand v0.9.5
Adding rand v0.10.2
Updating regex v1.12.4 -> v1.13.0
Updating regex-automata v0.4.14 -> v0.4.15
Updating rust-embed v8.11.0 -> v8.12.0
Updating rust-embed-impl v8.11.0 -> v8.12.0
Updating rust-embed-utils v8.11.0 -> v8.12.0
Updating rustls v0.23.40 -> v0.23.41
Updating rustls-pki-types v1.14.1 -> v1.15.0
Updating rustversion v1.0.22 -> v1.0.23
Updating sha1 v0.10.6 -> v0.10.7
Updating sha2 v0.10.9 -> v0.11.0
Updating syn v2.0.117 -> v2.0.118
Updating thread_local v1.1.9 -> v1.1.10
Removing unicode-xid v0.2.6
Removing wasip3 v0.4.0+wasi-0.3.0-rc-2026-01-06
Updating wasm-bindgen v0.2.125 -> v0.2.126
Updating wasm-bindgen-futures v0.4.75 -> v0.4.76
Updating wasm-bindgen-macro v0.2.125 -> v0.2.126
Updating wasm-bindgen-macro-support v0.2.125 -> v0.2.126
Updating wasm-bindgen-shared v0.2.125 -> v0.2.126
Removing wasm-encoder v0.244.0
Removing wasm-metadata v0.244.0
Removing wasmparser v0.244.0
Updating web-sys v0.3.102 -> v0.3.103
Updating webpki-root-certs v1.0.7 -> v1.0.8
Removing wit-bindgen v0.51.0
Removing wit-bindgen-core v0.51.0
Removing wit-bindgen-rust v0.51.0
Removing wit-bindgen-rust-macro v0.51.0
Removing wit-component v0.244.0
Removing wit-parser v0.244.0
Updating zerocopy v0.8.52 -> v0.8.54
Updating zerocopy-derive v0.8.52 -> v0.8.54
Updating zlib-rs v0.6.3 -> v0.6.6
Updating zmij v1.0.21 -> v1.0.22
```
quick-xml upgraded to 0.41
tower-http upgraded to 0.7
tokio-tungstenite upgraded to 0.30
No code changes needed.
Changelog-None
This commit is a routine update of third-party Rust libraries used by Core Lightning's REST and WebSocket proxy plugins. The author says no code changes were needed. It is not a security patch itself, but keeping dependencies current can prevent future security issues from known vulnerabilities in older library versions.
81443075 · Jul 14, 2026 · 2 filesInformational 15autogenerate-rpc-examples.py: disable entropy for generation.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes Core Lightning's internal test tooling so that automatically generated RPC documentation examples use predictable randomness and a fixed clock time. It only affects test/example generation code, not the production Lightning node software that users run. There is no security issue here; it is a developer convenience change to make generated documentation reproducible.
145edea5 · Jul 14, 2026 · 1 fileInformational 15autogenerate-rpc-examples.py: remove example mangling.
We temporarily add a flake8 exception so it doesn't complain about all
the now-unused variables.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a cleanup of a test script that generates example outputs for documentation. It removes a large amount of code that was manually replacing real test values with fake placeholder values in the generated examples. The script now stores the real test values directly instead of mangling them. There is no change to the actual Core Lightning node software, its RPC behavior, or its security.
68507fe2 · Jul 14, 2026 · 1 fileInformational 15autogenerate-rpc-examples.py: remove unused vars
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a routine cleanup of a test script. It removes variables that were assigned but never used, and deletes a couple of unused example data structures. There is no change to the actual Core Lightning node software, no change to how it handles money or network messages, and no security relevance.
0dd214af · Jul 14, 2026 · 1 fileInformational 15autogenerate-rpc-examples.py: canned blocks.
Unless REGENERATE_BLOCKCHAIN is true, in which case we make them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit changes only a test helper script that generates example outputs for RPC documentation. It introduces the ability to use pre-recorded ('canned') Bitcoin blockchain data instead of always generating a fresh one. There is no change to production code, wallet handling, networking, or cryptography, and no security relevance is apparent.
4b762330 · Jul 14, 2026 · 2 filesInformational 14autogenerate-rpc-examples.py: rewrite problematic examples.
And hand in CLN_NEXT_VERSION to replace the version string.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is a test and documentation tooling change. It improves a Python script that auto-generates example RPC outputs for Core Lightning's documentation, making the generated examples more stable across versions and test runs. There is no indication it fixes a security vulnerability or changes production code.
c928c573 · Jul 14, 2026 · 1 fileInformational 15autogenerate-rpc-examples.py: parameterized base port and cln next version
This commit is a maintenance update to a test helper script that auto-generates example RPC output for documentation. It makes the base network port and the next Core Lightning version configurable via environment variables, updates hard-coded node IDs used in examples, adjusts a few test amounts and adds some node shutdown calls. There is nothing here that affects real users' funds, network security, or production code.
c56990f7 · Jul 14, 2026 · 1 fileInformational 15autogenerate-rpc-examples.py: added wait functions like wait_for_htlcs_settled, wait_for_wallet_txs
This commit only changes an internal test script that automatically generates documentation examples for RPC commands. It adds wait helpers so the example generator pauses until payments and wallet transactions finish updating, making the generated examples more consistent. There is no change to the actual Core Lightning node software, network protocol, or wallet logic that users run.