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 9 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.
e04d2f93 · Jul 10, 2026 · 1 fileInformational 15CI: install CLN on macos and run selected pytest tests
remove the manual node start as it is covered by running pytests
Changelog-None
This commit only changes the project's macOS CI workflow. It replaces a manual setup that started Bitcoin and Core Lightning manually with an automated pytest-based test run after installing the software. There is no change to the actual Core Lightning code, user-facing behavior, or security-sensitive logic.
730e5881 · Jul 10, 2026 · 2 filesLow 25connectd: set IPV6_V6ONLY=1 on IPv6 sockets for consistent dual-stack behaviour
Systems with net.ipv6.bindv6only=0 (macOS, Fedora, Arch, vanilla kernels) create dual-stack sockets by default: binding '::' also covers '0.0.0.0', so the subsequent IPv4 wildcard bind fails with EADDRINUSE. Debian/Ubuntu ship bindv6only=1 so both binds succeed here, which is why this was never noticed on typical Linux CI.
Explicitly set IPV6_V6ONLY=1 on AF_INET6 sockets before bind so both address families always get independent sockets regardless of the system sysctl. Also free the errstr allocation left behind when the IPv4 bind fails acceptably (IPv6 succeeded), fixing a memleak in connectd on those systems.
test_ipv4_and_ipv6: accept IPv6-only binding in the single-socket case, which can still occur on IPv4-only hosts.
Changelog-Fixed: connectd: on macOS and other systems with dual-stack IPv6 default, wildcard '--addr=:<port>' now correctly binds both IPv4 and IPv6.
This commit fixes a network setup bug in Core Lightning's connection daemon. On some operating systems (macOS, Fedora, Arch, and default Linux kernels), an IPv6 'listen on all addresses' socket was also covering IPv4, which prevented a separate IPv4 socket from starting and could leak a small amount of memory when the IPv4 bind failed. The patch forces IPv6 sockets to be IPv6-only before binding, so IPv4 and IPv6 listeners are always created independently, and it frees an unused error message to stop the memory leak. It is a reliability/availability fix, not a direct remote exploit.
381c086e · Jul 9, 2026 · 2 filesInformational 19pyln-proto: update coincurve to commit 7829b29c08ebb1cc80386a1cdaf8c2243c4ef5c5
```
DEBUG: DEBUG ERROR: Use build.verbose instead of cmake.verbose for scikit-build-core >= 0.10
DEBUG: × Failed to build `coincurve==20.0.0`
DEBUG: ├─▶ The build backend returned an error
DEBUG: ╰─▶ Call to `hatchling.build.build_wheel` failed (exit status: 7)
DEBUG:
DEBUG: [stderr]
DEBUG: ERROR: Use build.verbose instead of cmake.verbose for scikit-build-core
DEBUG: >= 0.10
DEBUG:
DEBUG:
DEBUG: hint: `coincurve` (v20.0.0) was included because `testpluguv` (v0.1.0) depends on `pyln-client` (v26.6.2) which depends on `pyln-proto` (v26.6.2) which depends on `coincurve`
```
This error is caused because coincurve v20 depends on scikit-build-core>=0.9.0 and they did a new release where
using cmake.verbose is no longer a warning but an error. coincurve v21 is using the correct build.verbose but is not
working with python 3.14. So we update coincurve to current master until the next release.
Changelog-None
This change swaps a Python cryptography helper library (coincurve) from a pinned released version to a specific unreleased commit on GitHub. The stated reason is a build failure caused by a newer release of the build tool scikit-build-core, not a security bug. It is a build-compatibility fix, but it introduces a small risk because the project now depends on an unreleased snapshot of code instead of a stable, audited release.
9c378dd2 · Jul 8, 2026 · 10 filesInformational 15Fix listconfigs and lightningd-config documentation
- Fix `check-config-docs` script and it is using `jq` now
- `check-config-docs` skips options listed in doc/undoc-flags.list
- Add missing fields and deprecation information in listconfigs
- Add missing field in lightningd-config
- Other build generated updates
This commit is a documentation and generated-code synchronization fix. It updates the list of configuration options returned by the listconfigs RPC, marks several old options as deprecated, and regenerates the matching gRPC/JSON schema/Rust model files. There is no change to how the lightning node actually processes configuration values or handles network traffic, so it does not create or fix a security vulnerability.
90c27f91 · Jul 8, 2026 · 1 fileInformational 15CODEOWNERS: add daywalker90 as owner of bip353, currencyrate, and clnrest plugins
Changelog-None
This commit only updates the GitHub CODEOWNERS file, which assigns reviewers to certain plugin directories. It does not change any source code, build scripts, or runtime behavior of Core Lightning. There is no security-relevant change.
9b6a80fc · Jul 8, 2026 · 2 filesLow 43lightningd: accept OP_RETURN closer_scriptpubkey in simple-close check
A peer's closing_complete may set closer_scriptpubkey to a spec-valid
OP_RETURN, but close_tx_check only whitelisted the two stored shutdown
scripts, so master rejected our own signed tx and force-closed the
channel. Accept a zero-value OP_RETURN output, only when
option_simple_close is negotiated. Adds a regression test.
Reported-by: 0xaudron
Changelog-None: option_simple_close is experimental and unreleased.
This commit fixes a bug in Core Lightning's experimental simple-close feature. When two Lightning nodes tried to close a channel cooperatively using the new 'simple close' protocol, one peer was allowed by the specification to burn its own share of the funds to an unusable 'OP_RETURN' output instead of sending it to a normal address. Core Lightning's safety check did not recognize this valid case, so it rejected the mutually signed closing transaction and force-closed the channel on-chain instead. The fix teaches Core Lightning to accept a zero-value OP_RETURN output from the peer, but only when simple close was negotiated and only if the output carries no funds. A regression test is included.
5ae0705f · Jul 8, 2026 · 1 fileInformational 15tests: fix flaky test_simple_close_delay_broadcast mempool race
The test mined a block as soon as 'Broadcasting txid' appeared in l2's
log, but that log fires when CLN calls sendrawtransaction, not when
bitcoind has accepted the tx into its mempool. Under rpcproxy timing the
block could be mined empty, leaving the funding output unspent so
'Resolved FUNDING_TRANSACTION/FUNDING_OUTPUT by MUTUAL_CLOSE' never
logged and the test timed out.
Wait for the tx to enter the mempool before generating the block.
Changelog-None
This commit fixes a flaky automated test in Core Lightning. The test was sometimes failing because it mined a Bitcoin block immediately after seeing a log message that said a transaction was being broadcast. That log appears when Core Lightning submits the transaction, not when Bitcoin actually accepts it into the memory pool. Under timing variations, the block could be mined before the transaction arrived, producing an empty block and causing the test to time out. The fix waits for the transaction to enter the memory pool before mining. This is a test-only change and does not affect production code or user funds.
2d367bef · Jul 7, 2026 · 1 fileInformational 15CODEOWNERS: add self as owner of xpay/askrene/renepay
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This commit only updates the GitHub CODEOWNERS file to assign one developer as the automatic reviewer for several plugin directories and their test files. It makes no code changes and has no security relevance.
ec7d544c · Jul 7, 2026 · 2 filesInformational 15tests: lower testpluguv's required python version
uv would use python 3.14 which currently leads to an error because of a build dependency update
```
× 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`
```
Changelog-None
This commit is a test-only build fix. It lowers the minimum Python version required for a small test plugin from 3.13 to 3.10 so that the project's test tooling can install a dependency that currently fails to build on Python 3.14. It does not change Core Lightning's runtime code, network protocol, or wallet handling, and it does not fix or introduce a security vulnerability.
2e6ae4cd · Jul 7, 2026 · 1 fileInformational 15Makefile: fix depedency of autogenerated files
`check-gen-updated` correctly depends on `CLN_GRPC_GENALL` but the
latter does not list the pyln-grpc-proto generated files, we fix that.
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This is a one-line build-system fix in the Makefile. It adds generated Python gRPC files to a list used for dependency tracking during build checks. There is no indication of any security issue, vulnerability, or runtime behavior change. It simply ensures the build system knows about all generated files so checks can run correctly.
45b04dc0 · Jul 7, 2026 · 1 fileInformational 15Makefile: restrict git diff check
The targets `check-doc-examples` and `check-wire-format` use a plain
`git diff --exit-code HEAD` command to check differences in the wire and
doc files. They also hit every other autogenerated files thus racing
against `$(GRPC_GEN)` targets even though the're conceptually not
related.
We restrict the scope of `check-doc-examples` to the doc directory and
`check-wire-format` to fix the conflict.
Fixes flake in CI pre-build checks:
```
git diff --exit-code HEAD
diff --git a/contrib/pyln-grpc-proto/pyln/grpc/node_pb2.py b/contrib/pyln-grpc-proto/pyln/grpc/node_pb2.py
index ba3afd54f..935897050 100644
Binary files a/contrib/pyln-grpc-proto/pyln/grpc/node_pb2.py and b/contrib/pyln-grpc-proto/pyln/grpc/node_pb2.py differ
diff --git a/contrib/pyln-grpc-proto/pyln/grpc/node_pb2_grpc.py b/contrib/pyln-grpc-proto/pyln/grpc/node_pb2_grpc.py
index ab8bd868c..34a1eeaa2 100644
--- a/contrib/pyln-grpc-proto/pyln/grpc/node_pb2_grpc.py
+++ b/contrib/pyln-grpc-proto/pyln/grpc/node_pb2_grpc.py
@@ -3,7 +3,7 @@
import grpc
import warnings
-from pyln.grpc import node_pb2 as node__pb2
+import node_pb2 as node__pb2
GRPC_GENERATED_VERSION = '1.75.1'
GRPC_VERSION = grpc.__version__
find contrib/pyln-grpc-proto/pyln/ -type f -name "*.py" -print0 | xargs -0 sed -i'.bak' -e 's/^import \(.*\)_pb2 as .*__pb2/from pyln.grpc import \1_pb2 as \1__pb2/g'
find contrib/pyln-grpc-proto/pyln/ -type f -name "*.py.bak" -print0 | xargs -0 rm -f
make: *** [Makefile:670: check-wire-format] Error 1
```
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
This is a build-system fix for a flaky CI test. It narrows two 'git diff' checks so they only look at the specific directories they are meant to validate, instead of scanning the entire repository. There is no security issue here.
cb07b8cb · Jul 7, 2026 · 4 filesLow 47ccan: update ccan to fe99a8e0
Includes rustyrussell/ccan#129, which replaces asort's old quicksort
fallback with glibc 2.43's mergesort+heapsort. The old fallback called
cmp(pivot, pivot) on all-equal arrays, violating the comparator contract
that pointer identity implies distinct elements. Mergesort never
self-compares, matching qsort_r behaviour on systems without it.
This unblocks removing the temporary self-comparison guard in
cmp_rr_number().
Changelog-None
This commit updates an internal sorting library used by Core Lightning. The old sorting code could call a comparison function with the exact same item twice when sorting arrays where every element is equal. The commit replaces that old code with a newer version that never does this, and adds tests to confirm. The change is defensive: it removes a place where a comparator could receive an unexpected self-comparison, which could in theory cause bugs or crashes if a comparator assumed the two pointers would always be different.
d94b37b8 · Jul 6, 2026 · 3 filesInformational 19cln-plugin: include the full error chain when given a context
Changelog-None
This commit improves error messages in Core Lightning's Rust plugin library. When a plugin method fails and the error has extra context attached (using the popular Rust 'anyhow' error library), the plugin now returns the full chain of error messages to the caller instead of only the last message. This is a diagnostic-quality improvement, not a fix for a vulnerability.
17abce24 · Jul 6, 2026 · 1 fileInformational 15lsps-plugin: print whole error chain for HtlcError
This commit changes three error-message format strings in the LSPS (Lightning Service Provider Specification) plugin so that when an HTLC-related error occurs, the entire chain of underlying causes is printed instead of just the top-level message. It is a logging/diagnostics improvement with no apparent security impact.
50942584 · Jul 6, 2026 · 1 fileInformational 15pytests: fix flakyness on test_no_delay: introduced statistical margin instead of fixed amount to reduce flakiness
Changelog-None
This commit only changes a single test file to make a flaky timing test more reliable. It does not modify any production code, network protocol handling, or user-facing behavior. There is no security issue here.
0da8fa28 · Jul 6, 2026 · 1 fileInformational 15ci: reduce sanitizer/valgrind worker count to avoid runner OOM
The ASan/UBSan and Valgrind shards intermittently have their hosted
runner killed mid-run with "The runner has received a shutdown signal",
surfaced as a mass test cancellation. The VM itself is being
terminated, most likely from memory exhaustion: `-n $(nproc)+1` runs 5
parallel node-clusters and ASan roughly triples RSS, peaking past the
16GB hosted-runner ceiling on heavy shards (deterministic repro at ~10%
on ASan/UBSan 3/6 due to the fixed --test-group-random-seed=42).
Drop these two jobs to `-n $(nproc)` (one fewer worker) to lower peak
memory, and add an `if: failure()` step that dumps OOM-related dmesg and
kernel-log lines so the next failure records the actual cause.
Changelog-None
This change only adjusts the project's automated testing setup. It reduces the number of parallel test workers in two CI jobs to stop GitHub's hosted test machines from running out of memory, and adds logging to confirm the cause if they still fail. It does not change the Core Lightning software that users run, and there is no security issue here.
40f2ce6a · Jul 3, 2026 · 2 filesInformational 15connectd/tests: fix test_announce_and_connect_via_dns on macOS
localhost.localdomain is not present in /etc/hosts on macOS by default,
so the test's DNS-resolve step fails immediately. Any hostname that
does resolve on macOS (e.g. test.localhost via mDNSResponder) causes
mDNSResponder to open temporary sockets which dev_report_fds() flags
as unowned (BROKEN) at teardown.
Skip the test explicitly on macOS with @unittest.skipIf so the reason
is visible and trackable. A follow-up can fix dev_report_fds to
tolerate resolver sockets and re-enable the test on macOS.
Changelog-None
This commit is a test-only fix for macOS. It skips a test that fails because macOS lacks a specific local hostname entry, and it adds a code comment explaining a networking flag. There is no security issue or vulnerability here.
da67bf84 · Jul 2, 2026 · 4 filesLow 35simpleclosed.c: add heuristic to delay our tx broadcast if our amount is less AND our fee is less than our peer's amount and fee
in case of a reboot the tx will be broadcast as usual.
simple_close_control.c: add delay logic to `drop_to_chain` after 1 hour.
test_closing.py: add test to verify the heuristic is being applied.
This commit adds a one-hour delay before Core Lightning broadcasts a mutual channel-close transaction when the local node has the smaller payout and proposed a lower fee than its peer. The goal is to let the peer's higher-fee transaction win the race to be mined first, reducing the chance that both nodes broadcast competing close transactions after a restart. It is a protocol-robustness improvement, not a fix for an active exploit.
281ad119 · Jul 2, 2026 · 2 filesInformational 15test: add run-close_tx to validate simple-close transaction functionality
Why it was queuedThis commit only adds a new unit test file and updates the build Makefile to compile it. It does not change any production code, so it cannot introduce a runtime security vulnerability by itself. The test exercises the existing create_simple_close_tx function with various valid and edge-case inputs to make sure it behaves as expected.
ce119cd2 · Jul 2, 2026 · 7 filesLow 37lightningd: wire up `option_simple_close` master-side handling
Adds the master-side glue for the `simpleclosed` subdaemon and removes the xfail markers from the integration tests:
- simple_close_control.c:
- starts the daemon with feerate bounds and shutdown scripts;
- handles SIMPLECLOSED_GOT_SIG (broadcast closer tx), SIMPLECLOSED_CLOSEE_BROADCAST (broadcast closee tx), and SIMPLECLOSED_COMPLETE (advance state, resolve close RPC)
- channel_control.c: route to peer_start_simpleclosed() instead of peer_start_closingd() when OPT_SIMPLE_CLOSE is negotiated;
- peer_control.c: drop_to_chain_simple_close() sets up the funding-spend watch and resolves the close RPC without broadcasting the commitment tx, avoids it RBF-replacing the mutual close txs;
- resend_closing_transactions() uses the same variant on restart
Changelog-Experimental: Protocol: implement `option_simple_close` (BOLT2) for simpler one-shot mutual close fee negotiation. Enable with --dev-force-features=+60.
This commit turns on a new experimental Lightning feature called 'simple close' (BOLT2 option_simple_close). It adds the master-side code that starts a new subdaemon, validates mutual-close transactions, stores them, and broadcasts them instead of the older commitment transaction. The change removes 'expected to fail' markers from five integration tests, meaning the feature is now considered functional. It is a protocol implementation patch, not a fix for a known vulnerability, and it is gated behind a developer-only feature flag.
9f2f4350 · Jul 2, 2026 · 5 filesLow 35closingd: add `lightning_simpleclosed` for `option_simple_close`
New subdaemon implementing the BOLT2 simple close protocol, replacing `lightning_closingd` when `option_simple_close` is negotiated:
- Each peer independently sends `closing_complete` with their fee proposal;
- The other side signs it and sends `closing_sig`;
- Both sides broadcast two conflicting closing transactions and whichever confirms first wins.
Key protocol details:
- Closer pays the fee and closee receives their exact channel balance;
- TLV variants selected per BOLT2: `closer_output_only`, `closer_and_closee_outputs`, `closee_output_only`;
- Sequence 0xFFFFFFFD enables RBF via re-sending `closing_complete`;
- Script mismatch on `closee_scriptpubkey` warns and fails to reconnect;
common/shutdown_scriptpubkey.h/c: removed `static` from `is_valid_op_return` so it can be used in `simpleclosed.c`
This commit adds a new sub-program (lightning_simpleclosed) to Core Lightning that implements a new, simpler way for two Lightning nodes to agree on closing a payment channel together. It is a feature addition, not a documented security fix. The code introduces new message handling, transaction signing, and fee logic, which naturally carries implementation risk, but the commit message and diff do not describe any known vulnerability or attack.
e081eb3e · Jul 2, 2026 · 1 fileLow 33channeld: reject `closing_complete` and `closing_sig` with a clear error
When `option_simple_close` is negotiated the master launches `simpleclosed`
after `channeld` exits, so `closing_complete` and `closing_sig` should never
arrive inside `channeld`. Add stubs that call peer_failed_warn() with an
informative message rather than hitting the default unknown-message path.
This change makes a Lightning node respond with a clear warning error if a peer sends certain closing-related messages at the wrong time, instead of silently following the default 'unknown message' path. It is a hardening fix that prevents potential confusion or protocol mishandling during channel close, but it does not by itself grant an attacker new capabilities.
ff9e556c · Jul 2, 2026 · 14 filesInformational 15common: add `OPT_SIMPLE_CLOSE` feature bit (60/61)
features.h: Reserves bits 60/61 for `option_simple_close` per BOLT2.
features.c: Add `OPT_SIMPLE_CLOSE` to `feature_styles[]` and declare the correct `feature_name`.
tests/test_closing.py: Update options on `test_simple_close_...` to include `{experimental-simple-close: None}`.
lightningd/options.c: Register noarg option for simple close.
doc/schemas/listconfigs.json: add `experimental-simple-close` to config targeting v26.08.
doc/lightningd-config.5.md: Specify `experimental-simple-close` option.
contrib/pyln-testing/pyln/testing/utils.py: Allow setting `EXPERIMENTAL_SIMPLE_CLOSE` on tests.
Generated files after modifying sources.
This commit adds a new experimental Lightning protocol feature called 'simple close' (feature bits 60/61). It is purely a feature flag and configuration plumbing change: it reserves the feature bit, registers a command-line option, and updates generated RPC/protobuf schemas so the new option appears in configuration listings. There is no actual implementation of the simple-close protocol logic here, and nothing in the diff changes how funds, signatures, or peer messages are handled.
e362c3bb · Jul 2, 2026 · 2 filesInformational 12common/close_tx: add `create_simple_close_tx()` for `option_simple_close`
Adds the BOLT3 simple closing transaction builder:
- sequence 0xFFFFFFFD (RBF-signalling)
- locktime from closing_complete
- closer pays fee (their output is reduced)
- dust outputs are omitted and a zero-value OP_RETURN is used when both outputs would be dust.
This commit adds a new helper function that builds a specific kind of Bitcoin closing transaction used by the Core Lightning node software when two channel peers agree on a simpler cooperative close. It follows the BOLT 3 specification, sets the transaction version and sequence number to signal replace-by-fee, uses a locktime supplied by the peer that initiated the close, subtracts the closing fee from the closer's output, and drops tiny 'dust' outputs by turning them into zero-value data outputs. There is no indication in the commit that this fixes a security bug; it appears to be a feature implementation for a new protocol option.
7640ab6b · Jul 2, 2026 · 1 fileInformational 15tests: `add option_simple_close` integration tests
Four tests for the `option_simple_close` protocol (BOLT #2, bit 60). `test_simple_close_no_feature_fallback` exercises the existing legacy `closingd` path and passes now; the other three are marked xfail until the implementation lands:
- test_simple_close_basic: happy path; both nodes exchange
closing_complete/closing_sig, each broadcasts two conflicting txs,
the winner confirms, both nodes detect their output CONFIRMED
- test_simple_close_closer_pays_fee: closer bears the fee, closee
receives their exact pre-close balance
- test_simple_close_dust_output_omitted: closee output below dust is
omitted from the closing tx (closer_output_only variant)
- test_simple_close_no_feature_fallback: without bit 60, nodes fall
back to legacy closingd
- test_simple_close_restart: re-transmit our simple_close transaction after restart
- test_simple_close_closee_path: the closee (peer) transaction is stored
This commit only adds new automated tests for an upcoming Lightning protocol feature called option_simple_close. It does not change any production code. Most of the new tests are explicitly marked as expected to fail (xfail) because the feature is not fully implemented yet. One test verifies the existing legacy closing behavior still works. There is no security vulnerability introduced or fixed here.