From 3c722437a68972b0f7797ccce7b850c58c2034b7 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:21:28 +0200 Subject: [PATCH 01/29] docs: fixed `elergencyrecover` hyperlink --- doc/beginners-guide/backup-and-recovery/recovery.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/beginners-guide/backup-and-recovery/recovery.md b/doc/beginners-guide/backup-and-recovery/recovery.md index 34b55e7bac16..a4a0e7e9de2c 100644 --- a/doc/beginners-guide/backup-and-recovery/recovery.md +++ b/doc/beginners-guide/backup-and-recovery/recovery.md @@ -16,7 +16,7 @@ privacy: - Copy the valid binary formatted `hsm_secret` into `$LIGHTNINGDIR` directory - Copy the latest `emergency.recover` backup file into the `$LIGHTNINGDIR` before starting up the node - Start `lightningd` - - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/lightning-emergencyrecover] to recover all the channels on the node + - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/emergencyrecover] to recover all the channels on the node - Wait until your peer force closes the channel and the node would automatically sweep the funds. This could take some time @@ -29,11 +29,11 @@ privacy: - Run `lightning-cli emergencyrecover` (RPC command)[https://docs.corelightning.org/reference/lightning-emergencyrecover] to recover all the channels on the node -> 🚧 +> 🚧 > > **Only** recover from database if you are sure that it is **latest**. > -> Snapshot-style backups of the lightningd database is **discouraged**, as _any_ loss of state may result in permanent loss of funds. +> Snapshot-style backups of the lightningd database is **discouraged**, as _any_ loss of state may result in permanent loss of funds. > > See the [penalty mechanism](https://github.com/lightning/bolts/blob/master/05-onchain.md#revoked-transaction-close-handling) for more details. From d9368df10cd7fc267f5da95b3f5ca2b35e8b74d5 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:26:01 +0200 Subject: [PATCH 02/29] docs: fixing broken hyperlink on `createrune`, `showrunes`, and `getinfo` on app-development/rest page --- doc/developers-guide/app-development/rest.md | 24 ++++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/developers-guide/app-development/rest.md b/doc/developers-guide/app-development/rest.md index a71fadce280c..eac7c1b014c0 100644 --- a/doc/developers-guide/app-development/rest.md +++ b/doc/developers-guide/app-development/rest.md @@ -7,17 +7,17 @@ privacy: # CLNRest -CLNRest is a lightweight Rust-based built-in Core Lightning plugin (from v23.08) that transforms RPC calls into a REST service. -It also broadcasts Core Lightning notifications to listeners connected to its websocket server. By generating REST API endpoints, +CLNRest is a lightweight Rust-based built-in Core Lightning plugin (from v23.08) that transforms RPC calls into a REST service. +It also broadcasts Core Lightning notifications to listeners connected to its websocket server. By generating REST API endpoints, it enables the execution of Core Lightning's RPC methods behind the scenes and provides responses in JSON format. An online demo for the REST interface is available at [REST API REFERENCE](ref:get_list_methods_resource). > πŸ“˜ Pro-tip -> +> > [REST API REFERENCE](ref:get_list_methods_resource) can also be tested with your own server. > -> By default, the base URL is set to connect with the Blockstream-hosted regtest node. +> By default, the base URL is set to connect with the Blockstream-hosted regtest node. > > However, it can be configured to connect to your own cln node as described below: > @@ -45,13 +45,13 @@ If `clnrest-port` is not specified, the plugin will disable itself. - --clnrest-certs: Defines the path for HTTPS cert & key. Default path is same as RPC file path to utilize gRPC's client certificate. If it is missing at the configured location, new identity will be generated. -- --clnrest-csp: Creates a whitelist of trusted content sources that can run on a webpage and helps mitigate the risk of attacks. +- --clnrest-csp: Creates a whitelist of trusted content sources that can run on a webpage and helps mitigate the risk of attacks. Default CSP: `default-src 'self'; font-src 'self'; img-src 'self' data:; frame-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline';` Example CSP: `clnrest-csp=default-src 'self'; font-src 'self'; img-src 'self'; frame-src 'self'; style-src 'self'; script-src 'self';`. -- --clnrest-cors-origins: Define multiple origins which are allowed to share resources on web pages to a domain different from the +- --clnrest-cors-origins: Define multiple origins which are allowed to share resources on web pages to a domain different from the one that served the web page. Default is `*` which allows all origins. Example to define multiple origins: ``` @@ -65,14 +65,14 @@ clnrest-cors-origins=https?://127.0.0.1:([0-9]{1,4}|[1-5][0-9]{4}|6[0-4][0-9]{3} ## Server -With the default configurations, the Swagger user interface will be available at https://127.0.0.1:3010/. +With the default configurations, the Swagger user interface will be available at https://127.0.0.1:3010/. The POST method requires `rune` header for authorization. -- A new `rune` can be created via [createrune](https://docs.corelightning.org/reference/lightning-createrune) or the list of -existing runes can be retrieved with [showrunes](https://docs.corelightning.org/reference/lightning-showrunes) command. +- A new `rune` can be created via [createrune](https://docs.corelightning.org/reference/createrune) or the list of +existing runes can be retrieved with [showrunes](https://docs.corelightning.org/reference/showrunes) command. -Note: in version v23.08, a parameter `Nodeid` was required to be the id of the node we're talking to (see `id (pubkey)` received -from [getinfo](https://docs.corelightning.org/reference/lightning-getinfo)). You can still send this for backwards compatibility, +Note: in version v23.08, a parameter `Nodeid` was required to be the id of the node we're talking to (see `id (pubkey)` received +from [getinfo](https://docs.corelightning.org/reference/getinfo)). You can still send this for backwards compatibility, but it is completely ignored. ### cURL @@ -83,7 +83,7 @@ With `-k` or `--insecure` option curl proceeds with the connection even if the S This option should be used only when testing with self signed certificate. ## Websocket Server -Websocket server is available at `https://127.0.0.1:3010`. clnrest broadcasts notifications to all listeners. +Websocket server is available at `https://127.0.0.1:3010`. clnrest broadcasts notifications to all listeners. This websocket server requires a `rune` with at least `readonly` access for authorization. The default method used for current validation is `listclnrest-notifications`. User can either provided a rune with minimum `readonly` From 3d221db53af00e187e7964837c5d66ac39e1e328 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:29:28 +0200 Subject: [PATCH 03/29] docs: fixing hyperlink of python plugin tutorials --- doc/developers-guide/app-development/json-rpc.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/developers-guide/app-development/json-rpc.md b/doc/developers-guide/app-development/json-rpc.md index d061d55c39ab..e6799fe2b03d 100644 --- a/doc/developers-guide/app-development/json-rpc.md +++ b/doc/developers-guide/app-development/json-rpc.md @@ -4,8 +4,8 @@ slug: json-rpc privacy: view: public --- -> πŸ“˜ -> +> πŸ“˜ +> > Used for applications running on the same system as CLN. ## Using `lightning-cli` @@ -38,9 +38,9 @@ This will add links to the library into your environment so changing the checked Check out the following recipes to learn how to use pyln-client in your applications. -πŸ¦‰ **[Write a program in Python to interact with lightningd](https://docs.corelightning.org/v1.0/recipes/write-a-program-in-python-to-interact-with-lightningd)** +πŸ¦‰ **[Write a program in Python to interact with lightningd](https://docs.corelightning.org/recipes/write-a-program-in-python-to-interact-with-lightningd)** -πŸ¦‰ **[Write a hello-world plugin in Python](https://docs.corelightning.org/v1.0/recipes/write-a-hello-world-plugin-in-python)** +πŸ¦‰ **[Write a hello-world plugin in Python](https://docs.corelightning.org/recipes/write-a-hello-world-plugin-in-python)** ## Using Rust From e589c0adae7b3954bb5c94958f9f48663fb674fa Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:31:54 +0200 Subject: [PATCH 04/29] docs: fixing hyperling of BOLT9 github page --- .../a-day-in-the-life-of-a-plugin.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md index 8aea0df625e9..b90eab83e361 100644 --- a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md +++ b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md @@ -6,10 +6,10 @@ privacy: --- A plugin may be written in any language, and communicates with `lightningd` through the plugin's `stdin` and `stdout`. JSON-RPCv2 is used as protocol on top of the two streams, with the plugin acting as server and `lightningd` acting as client. The plugin file needs to be executable (e.g. use `chmod a+x plugin_name`). -> 🚧 -> +> 🚧 +> > As noted, `lightningd` uses `stdin` as an intake mechanism. This can cause unexpected behavior if one is not careful. To wit, care should be taken to ensure that debug/logging statements must be routed to `stderr` or directly to a file. Activities that are benign in other contexts (`println!`, `dbg!`, etc) will cause the plugin to be killed with an error along the lines of: -> +> > `UNUSUAL plugin-cln-plugin-startup: Killing plugin: JSON-RPC message > does not contain "jsonrpc" field` @@ -108,12 +108,12 @@ The `nonnumericids` indicates that the plugin can handle string JSON request `id The `dynamic` indicates if the plugin can be managed after `lightningd` has been started using the [lightning-plugin](ref:plugin) JSON-RPC command. Critical plugins that should not be stopped should set it to false. Plugin `options` can be passed to dynamic plugins as argument to the `plugin` command . If you can handle the `check` command on your commands, you should set `cancheck` to `true` and expect `lightningd` to pass through any user-requested `check` commands to you directly (without this, `check` currently always passes, which is not very useful!). - + If a `disable` member exists, the plugin will be disabled and the contents of this member is the reason why. This allows plugins to disable themselves if they are not supported in this configuration. The `hooks` array is either an array of hook names, or an array of objects with `name`, and optional `before` and `after` arrays specifying what the calling order is with respect to any other plugins (there's no problem if these plugins don't exist, but if they do we'll insist on obeying everyone's ordering constraints). You can also specify a `filters` array to some hooks to avoid being called on every occurrence. -The `featurebits` object allows the plugin to register featurebits that should be announced in a number of places in [the protocol](https://github.com/lightning/bolts/blob/master/09-features). They can be used to signal support for custom protocol extensions to direct peers, remote nodes and in invoices. Custom protocol extensions can be implemented for example using the `sendcustommsg` method and the `custommsg` hook, or the `sendonion` method and the `htlc_accepted` hook. The keys in the `featurebits` object are `node` for features that should be announced via the `node_announcement` to all nodes in the network, `init` for features that should be announced to direct peers during the connection setup, `channel` for features which should apply to `channel_announcement`, and `invoice` for features that should be announced to a potential sender of a payment in the invoice. The low range of featurebits is reserved for standardize features, so please pick random, high position bits for experiments. If you'd like to standardize your extension please reach out to the [specification repository][spec] to get a featurebit assigned. +The `featurebits` object allows the plugin to register featurebits that should be announced in a number of places in [the protocol](https://github.com/lightning/bolts/blob/master/09-features.md). They can be used to signal support for custom protocol extensions to direct peers, remote nodes and in invoices. Custom protocol extensions can be implemented for example using the `sendcustommsg` method and the `custommsg` hook, or the `sendonion` method and the `htlc_accepted` hook. The keys in the `featurebits` object are `node` for features that should be announced via the `node_announcement` to all nodes in the network, `init` for features that should be announced to direct peers during the connection setup, `channel` for features which should apply to `channel_announcement`, and `invoice` for features that should be announced to a potential sender of a payment in the invoice. The low range of featurebits is reserved for standardize features, so please pick random, high position bits for experiments. If you'd like to standardize your extension please reach out to the [specification repository][spec] to get a featurebit assigned. The `notifications` array allows plugins to announce which custom notifications they intend to send to `lightningd`. These custom notifications can then be subscribed to by other plugins, allowing them to communicate with each other via the existing publish-subscribe mechanism and react to events that happen in other plugins, or collect information based on the notification topics. From 7f9d1ed0ad37659b20326999a3f30f25c3c4dde4 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:35:29 +0200 Subject: [PATCH 05/29] docs: removed `sauron` from the plugin list recommended to use since it is archived in the plugin repository --- doc/getting-started/advanced-setup/bitcoin-core.md | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/getting-started/advanced-setup/bitcoin-core.md b/doc/getting-started/advanced-setup/bitcoin-core.md index 5335ae55120c..5462b262a776 100644 --- a/doc/getting-started/advanced-setup/bitcoin-core.md +++ b/doc/getting-started/advanced-setup/bitcoin-core.md @@ -21,6 +21,5 @@ In order to avoid this situation you should be monitoring the gap between Core L You can use _trusted_ third-party plugins as bitcoin backends instead of using your own node. -- [sauron](https://github.com/lightningd/plugins/tree/master/sauron) is a bitcoin backend plugin relying on [Esplora](https://github.com/Blockstream/esplora). - [trustedcoin](https://github.com/nbd-wtf/trustedcoin) is a plugin that uses block explorers (blockstream.info, mempool.space, blockchair.com and blockchain.info) as backends instead of your own bitcoin node. - [bps](https://github.com/coinos/bps) is a proxy server that exposes just the RPC commands that lightning needs. There's a public endpoint at https://coinos.io/proxy or you can host your own. From 77efb65f54d7445c5ed260961bd6654b2cfcec83 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:37:48 +0200 Subject: [PATCH 06/29] docs: removed link of `helpme` plugin since it has been archived in plugins repo --- README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/README.md b/README.md index 48445f7c5f6e..ddec8d282dce 100644 --- a/README.md +++ b/README.md @@ -228,6 +228,5 @@ Developers wishing to contribute should start with the developer guide [here](do [releases]: https://github.com/ElementsProject/lightning/releases [dockerhub]: https://hub.docker.com/r/elementsproject/lightningd/ [jsonrpcspec]: https://www.jsonrpc.org/specification -[helpme-github]: https://github.com/lightningd/plugins/tree/master/helpme [actions-badge]: https://github.com/ElementsProject/lightning/workflows/Continuous%20Integration/badge.svg [actions]: https://github.com/ElementsProject/lightning/actions From c1435327335616c414d7d19c45f39054c9aa9774 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:39:04 +0200 Subject: [PATCH 07/29] docs: fixing FAQ hyperlink --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ddec8d282dce..bd24555821aa 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ Core Lightning (previously c-lightning) is a lightweight, highly customizable an * [Sending and Receiving Payments](#sending-and-receiving-payments) * [Configuration File](#configuration-file) * [Further Information](#further-information) - * [FAQ](doc/FAQ.md) + * [FAQ](doc/node-operators-guide/faq.md) * [Pruning](#pruning) * [HD wallet encryption](#hd-wallet-encryption) * [Developers](#developers) From 854d7b23af6555dce88227419910eb2a1bf84f08 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 10:42:17 +0200 Subject: [PATCH 08/29] docs: fixed hyperlink to rpc-schema-draft.json --- .../coding-style-guidelines/writing-json-schemas.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contribute-to-core-lightning/coding-style-guidelines/writing-json-schemas.md b/doc/contribute-to-core-lightning/coding-style-guidelines/writing-json-schemas.md index 110793183487..7adecc3c4c53 100644 --- a/doc/contribute-to-core-lightning/coding-style-guidelines/writing-json-schemas.md +++ b/doc/contribute-to-core-lightning/coding-style-guidelines/writing-json-schemas.md @@ -17,7 +17,7 @@ Similarly, if you deprecate a field, add "deprecated": "VERSION" (where VERSION ## How to Write a Schema Name the schema doc/schemas/`command`.json: the testsuite should pick it up and check all invocations of that command against it. -The core lightning RPC commands use custom schema specification defined in [rpc-schema-draft](https://github.com/ElementsProject/lightning/doc/rpc-schema-draft.json). +The core lightning RPC commands use custom schema specification defined in [rpc-schema-draft](https://github.com/ElementsProject/lightning/blob/master/doc/rpc-schema-draft.json). I recommend copying an existing one to start. If something goes wrong, try tools/fromscheme.py doc/schemas/`command`.json to see how far it got before it died. From c648744857a7ab7a28941ffc6aa109037a731e4b Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:36:08 +0200 Subject: [PATCH 09/29] fdocs: fixed link and label of `bpftracer305` --- .../tracing-cln-performance.md | 41 ++++++------------- 1 file changed, 12 insertions(+), 29 deletions(-) diff --git a/doc/developers-guide/tracing-cln-performance.md b/doc/developers-guide/tracing-cln-performance.md index 47b322f80a61..4451eeddce5b 100644 --- a/doc/developers-guide/tracing-cln-performance.md +++ b/doc/developers-guide/tracing-cln-performance.md @@ -63,47 +63,34 @@ usdt:lightningd/lightningd:lightningd:span_start usdt:lightningd/lightningd:lightningd:span_suspend ``` -There is a sample exporter that can be used to instrument a single -binary, batch the spans it receives and submit them as a batch to an -`otelcol` or `tempo` instance in [contrib/cln-tracer][cln-tracer] -using the zipkin format for spans and traces. +There is a sample exporter that can be used to instrument a single binary, batch the spans it receives and submit them as a batch to an `otelcol` or `tempo` instance in [contrib/cln-tracer][cln-tracer] using the zipkin format for spans and traces. [cln-tracer]: https://github.com/ElementsProject/lightning/tree/master/contrib/cln-tracer -Notice that due to a [limitation][bpftracer305] in the way the eBPF -script is handled you'll at most get the first 495 bytes of the -payload. This is due to the 512 byte limitation for eBPF programs out -of the box. +Notice that due to a [limitation][bpftracer305] in the way the eBPF script is handled you'll at most get the first 495 bytes of the payload. This is due to the 512 byte limitation for eBPF programs out of the box. -[bpftracer]: https://github.com/iovisor/bpftrace/issues/305 +[bpftracer305]: https://github.com/bpftrace/bpftrace/issues/305 ## Backend 2: Unix Domain Socket Datagrams -The UDS backend sends completed spans as atomic datagrams to a Unix -domain socket. This is designed for environments where kernel eBPF -access is unavailable, such as Kubernetes pods. +The UDS backend sends completed spans as atomic datagrams to a Unix domain socket. This is designed for environments where kernel eBPF access is unavailable, such as Kubernetes pods. ### How it works -Set the `CLN_TRACE_SOCKET` environment variable to the filesystem path -of a `SOCK_DGRAM` Unix domain socket: +Set the `CLN_TRACE_SOCKET` environment variable to the filesystem path of a `SOCK_DGRAM` Unix domain socket: ```bash $ CLN_TRACE_SOCKET=/tmp/cln-traces.sock lightningd ``` -When a span completes, its Zipkin-format JSON payload is sent via -`sendto()` to the specified socket. Key properties: +When a span completes, its Zipkin-format JSON payload is sent via `sendto()` to the specified socket. Key properties: -- **Atomic delivery**: Each datagram contains a complete, self-contained - JSON span payload. No framing or reassembly needed. +- **Atomic delivery**: Each datagram contains a complete, self-contained JSON span payload. No framing or reassembly needed. - **Non-blocking**: The socket is set to `O_NONBLOCK`. If the collector - is down or the socket buffer is full, the `sendto()` silently fails - without affecting the node. + is down or the socket buffer is full, the `sendto()` silently fails without affecting the node. - **Multi-writer safe**: Multiple CLN daemons can write to the same - socket path concurrently. The kernel guarantees datagram boundaries - are preserved. + socket path concurrently. The kernel guarantees datagram boundaries are preserved. - **No USDT dependency**: Works on any system, regardless of whether `systemtap-sdt-dev` is installed or `HAVE_USDT` is set. @@ -120,13 +107,11 @@ Each datagram is a Zipkin v2 JSON array containing a single span: "traceId":"4bf92f3577b34da6a3ce929d0e0e4736"}] ``` -Payloads are capped at 2048 bytes, well below the UDS datagram limit -(~200KB on Linux). +Payloads are capped at 2048 bytes, well below the UDS datagram limit (~200KB on Linux). ### Setting up a collector -Any process that binds a `SOCK_DGRAM` Unix domain socket at the -configured path can receive spans. A minimal Python collector: +Any process that binds a `SOCK_DGRAM` Unix domain socket at the configured path can receive spans. A minimal Python collector: ```python import socket, os, json @@ -185,6 +170,4 @@ Benchmark 1: common/test/run-trace Range (min … max): 546.5 ms … 598.9 ms 10 runs ``` -So depending on whether an exporter is attached, creating and emitting -span without and with an exporter takes around 370ns and 560ns -respectively. +So depending on whether an exporter is attached, creating and emitting span without and with an exporter takes around 370ns and 560ns respectively. From fab2c23db0a14c343cfc919f0cba120e0808b3ee Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:38:48 +0200 Subject: [PATCH 10/29] docs: updated NixOS wiki link --- doc/getting-started/getting-started/installation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/getting-started/getting-started/installation.md b/doc/getting-started/getting-started/installation.md index 643a90d78e2b..5a8aff8fafbe 100644 --- a/doc/getting-started/getting-started/installation.md +++ b/doc/getting-started/getting-started/installation.md @@ -322,7 +322,7 @@ Finally, build `c-lightning`: ## To Build on NixOS -Core Lightning ships a [Nix flake](https://nixos.wiki/wiki/Flakes), so on NixOS +Core Lightning ships a [Nix flake](https://wiki.nixos.org/wiki/Flakes), so on NixOS you don't need to install any build dependencies by hand. Make sure the `nix-command` and `flakes` features are enabled. From 448138468f9c044719e46215f87d61bf2853dadf Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:46:44 +0200 Subject: [PATCH 11/29] docs: fixed ref link of json specs --- .../plugin-development/event-notifications.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/developers-guide/plugin-development/event-notifications.md b/doc/developers-guide/plugin-development/event-notifications.md index ce16cd78f048..7a1555e056d0 100644 --- a/doc/developers-guide/plugin-development/event-notifications.md +++ b/doc/developers-guide/plugin-development/event-notifications.md @@ -4,7 +4,7 @@ slug: event-notifications privacy: view: public --- -Event notifications allow a plugin to subscribe to events in `lightningd`. `lightningd` will then send a push notification if an event matching the subscription occurred. A notification is defined in the JSON-RPC [specification][jsonrpc-spec] as an RPC call that does not include an `id` parameter: +Event notifications allow a plugin to subscribe to events in `lightningd`. `lightningd` will then send a push notification if an event matching the subscription occurred. A notification is defined in the JSON-RPC [specification](https://www.jsonrpc.org/specification) as an RPC call that does not include an `id` parameter: > A Notification is a Request object without an "id" member. A Request object that is a Notification signifies the Client's lack of interest in the corresponding Response object, and as such no Response object needs to be returned to the client. The Server MUST NOT reply to a Notification, including those that are within a batch request. > @@ -12,8 +12,8 @@ Event notifications allow a plugin to subscribe to events in `lightningd`. `ligh Plugins subscribe by returning an array of subscriptions as part of the `getmanifest` response. The result for the `getmanifest` call above for example subscribes to the two topics `connect` and `disconnect`. -> πŸ“˜ -> +> πŸ“˜ +> > This is a way of specifying that you want to subscribe to all possible event notifications. It is not recommended, but is useful for plugins which want to provide generic infrastructure for others (in future, we may add the ability to dynamically subscribe/unsubscribe). Lookup the **[Notification APIs](ref:notification-balance_snapshot)** for details on each notification and their payload. From e4380f5bcf719e9e51ec401fbbe5c81c3d261ff6 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:49:52 +0200 Subject: [PATCH 12/29] docs: fixed ref of specs hyperlink --- .../plugin-development/a-day-in-the-life-of-a-plugin.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md index b90eab83e361..30bcd767e34c 100644 --- a/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md +++ b/doc/developers-guide/plugin-development/a-day-in-the-life-of-a-plugin.md @@ -113,7 +113,7 @@ If a `disable` member exists, the plugin will be disabled and the contents of th The `hooks` array is either an array of hook names, or an array of objects with `name`, and optional `before` and `after` arrays specifying what the calling order is with respect to any other plugins (there's no problem if these plugins don't exist, but if they do we'll insist on obeying everyone's ordering constraints). You can also specify a `filters` array to some hooks to avoid being called on every occurrence. -The `featurebits` object allows the plugin to register featurebits that should be announced in a number of places in [the protocol](https://github.com/lightning/bolts/blob/master/09-features.md). They can be used to signal support for custom protocol extensions to direct peers, remote nodes and in invoices. Custom protocol extensions can be implemented for example using the `sendcustommsg` method and the `custommsg` hook, or the `sendonion` method and the `htlc_accepted` hook. The keys in the `featurebits` object are `node` for features that should be announced via the `node_announcement` to all nodes in the network, `init` for features that should be announced to direct peers during the connection setup, `channel` for features which should apply to `channel_announcement`, and `invoice` for features that should be announced to a potential sender of a payment in the invoice. The low range of featurebits is reserved for standardize features, so please pick random, high position bits for experiments. If you'd like to standardize your extension please reach out to the [specification repository][spec] to get a featurebit assigned. +The `featurebits` object allows the plugin to register featurebits that should be announced in a number of places in [the protocol](https://github.com/lightning/bolts/blob/master/09-features.md). They can be used to signal support for custom protocol extensions to direct peers, remote nodes and in invoices. Custom protocol extensions can be implemented for example using the `sendcustommsg` method and the `custommsg` hook, or the `sendonion` method and the `htlc_accepted` hook. The keys in the `featurebits` object are `node` for features that should be announced via the `node_announcement` to all nodes in the network, `init` for features that should be announced to direct peers during the connection setup, `channel` for features which should apply to `channel_announcement`, and `invoice` for features that should be announced to a potential sender of a payment in the invoice. The low range of featurebits is reserved for standardize features, so please pick random, high position bits for experiments. If you'd like to standardize your extension please reach out to the [specification repository](https://github.com/lightning/bolts) to get a featurebit assigned. The `notifications` array allows plugins to announce which custom notifications they intend to send to `lightningd`. These custom notifications can then be subscribed to by other plugins, allowing them to communicate with each other via the existing publish-subscribe mechanism and react to events that happen in other plugins, or collect information based on the notification topics. From fd5ffa668e1a6d7bc66a6139f405bd2ab5df9563 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:52:20 +0200 Subject: [PATCH 13/29] docs: fixed `plugin` reference --- doc/developers-guide/plugin-development.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers-guide/plugin-development.md b/doc/developers-guide/plugin-development.md index c2014ba82990..3eb5ec8c443b 100644 --- a/doc/developers-guide/plugin-development.md +++ b/doc/developers-guide/plugin-development.md @@ -10,7 +10,7 @@ privacy: --- Plugins are a simple yet powerful way to extend the functionality provided by Core Lightning. They are subprocesses that are started by the main `lightningd` daemon and can interact with `lightningd` in a variety of ways: -- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to [`plugin start`][lightning-plugin]. +- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to [`plugin start`][ref:plugin]. - **[JSON-RPC command passthrough](doc:json-rpc-passthrough)** adds a way for plugins to add their own commands to the JSON-RPC interface. - **[Event stream subscriptions](doc:event-notifications)** provide plugins with a push-based notification mechanism about events from the `lightningd`. - **[Hooks](doc:hooks)** are a primitive that allows plugins to be notified about internal events in `lightningd` and alter its behavior or inject custom behaviors. From 4761b7e847de4ce9793a7cdb72df9832c585087e Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 11:56:45 +0200 Subject: [PATCH 14/29] docs: replacing BOLT12 reference from a personal fork to the official docs --- doc/lightningd-config.5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/lightningd-config.5.md b/doc/lightningd-config.5.md index aaa3e8fb8bc7..e8e67f476611 100644 --- a/doc/lightningd-config.5.md +++ b/doc/lightningd-config.5.md @@ -939,6 +939,6 @@ Note: the modules in the ccan/ directory have their own licenses, but the rest of the code is covered by the BSD-style MIT license. [bolt]: https://github.com/lightning/bolts -[bolt12]: https://github.com/rustyrussell/lightning-rfc/blob/guilt/offers/12-offer-encoding.md +[bolt12]: https://github.com/lightning/bolts/blob/master/12-offer-encoding.md [pr4421]: https://github.com/ElementsProject/lightning/pull/4421 [blip]: https://github.com/lightning/blips From df8e4bd6ebbed9bccd79fb721d2489b5f3196c4d Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 12:09:38 +0200 Subject: [PATCH 15/29] docs: switched from cross-page link to plain ancor since `installing-from-source` is in the same file --- doc/getting-started/getting-started/installation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/getting-started/getting-started/installation.md b/doc/getting-started/getting-started/installation.md index 5a8aff8fafbe..0a0aa60cf48e 100644 --- a/doc/getting-started/getting-started/installation.md +++ b/doc/getting-started/getting-started/installation.md @@ -23,7 +23,7 @@ sudo rm -R /usr/local/libexec/c-lightning/plugins # If you are upgrading run thi sudo tar -xvf .tar.xz -C /usr/local --strip-components=2 ``` -If you're on a different distribution or OS, you can compile the source by following the instructions from [Installing from Source](doc:installing-from-source). +If you're on a different distribution or OS, you can compile the source by following the instructions from [Installing from Source](#installing-from-source). # Docker From 9adad856216f18bb5c947dd57cf53e094834e1ce Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 12:12:25 +0200 Subject: [PATCH 16/29] docs: fixing slug of `hsm secret backup` --- doc/beginners-guide/beginners-guide.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/beginners-guide/beginners-guide.md b/doc/beginners-guide/beginners-guide.md index 430a28ad189b..c76680cb5512 100644 --- a/doc/beginners-guide/beginners-guide.md +++ b/doc/beginners-guide/beginners-guide.md @@ -57,4 +57,4 @@ Once you've started for the first time, there's a script called `contrib/bootstr There are also numerous plugins available for Core Lightning which add capabilities: see the [Plugins](doc:plugins) guide, and check out the plugin collection at: https://github.com/lightningd/plugins. -For a less reckless experience, you can encrypt the HD wallet seed: see [HD wallet encryption](doc:backup-and-recovery#hsm-secret-backup). +For a less reckless experience, you can encrypt the HD wallet seed: see [HD wallet encryption](doc:backup#hsm-secret-backup). From b647e4dac115323f2cfaed91d28b6a8a4f5fb552 Mon Sep 17 00:00:00 2001 From: enaples Date: Mon, 31 Aug 2026 12:16:31 +0200 Subject: [PATCH 17/29] docs: removed `(optional)` since it breaks the anchors --- doc/developers-guide/app-development/grpc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers-guide/app-development/grpc.md b/doc/developers-guide/app-development/grpc.md index 55c8725052de..50ffbc3baee8 100644 --- a/doc/developers-guide/app-development/grpc.md +++ b/doc/developers-guide/app-development/grpc.md @@ -102,7 +102,7 @@ Notice that we override the expected SSL name with `cln`. This is required becau We then use the channel to instantiate the `NodeStub` representing the service and its methods, so we can finally call the `Getinfo` method with default arguments. -### Generating custom certificates (optional) +### Generating custom certificates The automatically generated mTLS certificate will not know about potential domains that it'll be served under, and will chose a number of other parameters by default. If you'd like to generate a server certificate with a custom domain, you can use the following: From 32a9d7750560b6ecc1a3d8cb17252865c861a3f9 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:17:08 +0200 Subject: [PATCH 18/29] docs: bumping bitcoind version in docs --- README.md | 2 +- doc/getting-started/getting-started.md | 2 +- doc/getting-started/getting-started/installation.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index bd24555821aa..0824710ec582 100644 --- a/README.md +++ b/README.md @@ -37,7 +37,7 @@ Don't hesitate to reach out to us on the implementation-specific [mailing list][ ## Getting Started -Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 25.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`). +Core Lightning only works on Linux and macOS, and requires a locally (or remotely) running `bitcoind` (version 23.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`). Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](#pruning) for more details. ### Installation diff --git a/doc/getting-started/getting-started.md b/doc/getting-started/getting-started.md index a886105a8741..de380c6def16 100644 --- a/doc/getting-started/getting-started.md +++ b/doc/getting-started/getting-started.md @@ -26,7 +26,7 @@ The following steps will get you up and running with Core Lightning: For a thorough understanding of the best hardware setup for your usage / scenario, see guidance at [hardware considerations](doc:hardware-considerations). - [x] **Bitcoin Core** - Core Lightning requires a locally (or remotely) running `bitcoind` (version 0.16 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`). Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](doc:bitcoin-core#using-a-pruned-bitcoin-core-node) for more details. You can also connect your Core Lightning node to a remotely running Bitcoin Core, see [here](doc:bitcoin-core#connecting-to-bitcoin-core-remotely) to learn how. + Core Lightning requires a locally (or remotely) running `bitcoind` (version 23.0 or above) that is fully caught up with the network you're running on, and relays transactions (ie with `blocksonly=0`). Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](doc:bitcoin-core#using-a-pruned-bitcoin-core-node) for more details. You can also connect your Core Lightning node to a remotely running Bitcoin Core, see [here](doc:bitcoin-core#connecting-to-bitcoin-core-remotely) to learn how. ## 2. [Install](doc:installation) Core Lightning diff --git a/doc/getting-started/getting-started/installation.md b/doc/getting-started/getting-started/installation.md index 0a0aa60cf48e..7eeb3330c228 100644 --- a/doc/getting-started/getting-started/installation.md +++ b/doc/getting-started/getting-started/installation.md @@ -66,7 +66,7 @@ For actually doing development and running the tests, you will also need: - pip3: to install python-bitcoinlib - valgrind: for extra debugging checks -You will also need a version of bitcoind with segregated witness and `estimatesmartfee` with `ECONOMICAL` mode support. Version 0.16 or above should work. +You will also need a version of bitcoind with segregated witness and `estimatesmartfee` with `ECONOMICAL` mode support. Version 23.0 or above should work. ## To Build on Ubuntu From eadb71be63f48a84104f7e5a62379f7b656bc499 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:22:25 +0200 Subject: [PATCH 19/29] docs: update languages supported by reckless --- doc/node-operators-guide/plugins.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/doc/node-operators-guide/plugins.md b/doc/node-operators-guide/plugins.md index b3cd5a79440c..1f2e37d9e7d2 100644 --- a/doc/node-operators-guide/plugins.md +++ b/doc/node-operators-guide/plugins.md @@ -12,9 +12,9 @@ Power up your Core Lightning node and tailor it for your business needs with com `reckless` is a plugin manager for Core Lightning that you can use to install and uninstall plugins with a single command. -> πŸ“˜ -> -> Reckless currently supports python plugins only. Additional language support will be provided in future releases. For plugins built by the community in other languages, see the complete list of plugins [here](https://github.com/lightningd/plugins). +> πŸ“˜ +> +> Reckless currently supports both python and rust plugins only. Additional language support will be provided in future releases. For plugins built by the community in other languages, see the complete list of plugins [here](https://github.com/lightningd/plugins). Typical plugin installation involves: finding the source plugin, copying, installing dependencies, testing, activating, and updating the lightningd config file. Reckless does all of these by invoking: @@ -110,8 +110,8 @@ Available option flags: **-v**, **--verbose** request additional debug output -> πŸ“˜ -> +> πŸ“˜ +> > Running the first time will prompt the user that their lightningd's bitcoin config will be appended (or created) to inherit the reckless config file (this config is specific to bitcoin by default.) Management of plugins will subsequently modify this file. ## Troubleshooting From b9d86cf44668b13d3ce86c2b6300ae7e06507417 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:24:03 +0200 Subject: [PATCH 20/29] docs: bump version of Ubuntu in reproducible builds --- doc/contribute-to-core-lightning/release-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md index a3222c13bfd1..f83990ae06ea 100644 --- a/doc/contribute-to-core-lightning/release-checklist.md +++ b/doc/contribute-to-core-lightning/release-checklist.md @@ -71,7 +71,7 @@ Here's a checklist for the release process. 7. Run `tools/build-release.sh bin-Fedora bin-Ubuntu sign` (with `--sudo` if you need root to run Docker) to: - Create reproducible zipfile - Build reproducible Fedora image - - Build reproducible Ubuntu-v20.04, Ubuntu-v22.04 and Ubuntu-v24.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images. + - Build reproducible Ubuntu-v22.04, Ubuntu-v24.04 and Ubuntu-v26.04 images. Follow [link](https://docs.corelightning.org/docs/repro#building-using-the-builder-image) for manually Building Ubuntu Images. - Build Docker images for amd64 and arm64v8. Follow [link](https://docs.corelightning.org/docs/docker-images) for more details on Docker publishing. - Create and sign checksums. Follow [link](https://docs.corelightning.org/docs/repro#co-signing-the-release-manifest) for manually signing the release. 8. If you used `--sudo`, the tarballs may be owned by root, so revert ownership if necessary: `sudo chown ${USER}:${USER} *${VERSION}*` From fe0f792640c5c91bd27b710821a237a1c0bf0018 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:25:14 +0200 Subject: [PATCH 21/29] docs: fixed typoe - file does not exist --- doc/contribute-to-core-lightning/release-checklist.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md index f83990ae06ea..2a4ab6f0b5be 100644 --- a/doc/contribute-to-core-lightning/release-checklist.md +++ b/doc/contribute-to-core-lightning/release-checklist.md @@ -101,7 +101,7 @@ Here's a checklist for the release process. 1. Create a PR to update: * `Makefile`: variables CLN_NEXT_VERSION and CLN_PREV_VERSION (this may break tests as deprecated things are disabled!) - * `tools/lightningd-downgrade.c`: to downgrade to the just-released version. + * `tools/lightning-downgrade.c`: to downgrade to the just-released version. * `.github/workflows/ci.yaml`: change old-cln to download the just-released version. * `.github/PULL_REQUEST_TEMPLATE.md` for important dates for the next release. 2. Look through PRs which were delayed for release and merge them. From 5ed3072aa51a498112655405aaf80c6f69081141 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:27:07 +0200 Subject: [PATCH 22/29] docs: bump docker image version --- doc/getting-started/getting-started/installation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/getting-started/getting-started/installation.md b/doc/getting-started/getting-started/installation.md index 7eeb3330c228..7b6b2b3f4979 100644 --- a/doc/getting-started/getting-started/installation.md +++ b/doc/getting-started/getting-started/installation.md @@ -32,9 +32,9 @@ To install the Docker image for the latest stable release: docker pull elementsproject/lightningd:latest ``` -To install for a specific version, for example, 24.05: +To install for a specific version, for example, v26.06.6: ```shell -docker pull elementsproject/lightningd:v24.05 +docker pull elementsproject/lightningd:v26.06.6 ``` To run the Docker container: From abb4e3cf817c04d56fc4772eb8bec455337284da Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:31:19 +0200 Subject: [PATCH 23/29] docs: fixing docs building for new rpc call --- DEV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DEV.md b/DEV.md index f0a074d5baf9..1f22997e704a 100644 --- a/DEV.md +++ b/DEV.md @@ -9,7 +9,7 @@ - Commits which fix crashes or bug MUST quote the bug for later searches: do not rely on being able to find the bug report in future! - Commits which create signficant user (not developer!) visible changes should have Changelog-(Added|Deprecated|Changed|Fixed|EXPERIMENTAL) for assembling CHANGELOG.md at release time. - Deprecations must use the deprecation infrastructure, and append to the table in doc/developers-guide/deprecated-features.md -- Adding a new JSON-RPC command requires the most careful design: start with doc/schemas/NAME.json and add doc/NAME.json to MARKDOWNPAGES in doc/Makefile. `make doc-all` will regen the rest. +- Adding a new JSON-RPC command requires the most careful design: start with doc/schemas/NAME.json and add doc/NAME.7 to MARKDOWNPAGES in doc/Makefile. `make doc-all` will regen the rest. - In pytest integration tests, name nodes l1, l2, etc in creation order. This matches the log prefixes they use (`lightningd-1` etc) and on test failure the logs and other ephemera will in /tmp/ltests-*/TESTNAME*/lightning-1/. - In pytest, never assert that a command raises an exception without specifying *exactly what* it raises! Use `with pytest.raises(RpcError, match='xxx'):` - tal_bytelen / tal_count of NULL are defined to be zero, and you may assume this. From 9df736e30eb10a56f4efaf39625abbb34e7fb0bd Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:32:23 +0200 Subject: [PATCH 24/29] docs: fising how to build the debug build. `configure` is a script, not a flag --- DEV.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DEV.md b/DEV.md index 1f22997e704a..291709cd223c 100644 --- a/DEV.md +++ b/DEV.md @@ -1,4 +1,4 @@ -- Build with `--configure --enable-debugbuild` and `uv run make`. Much faster with `uv run make RUST=0`. +- Build with `./configure --enable-debugbuild` and `uv run make`. Much faster with `uv run make RUST=0`. - Env vars for tests: `RUST=0` (if RUST plugins were not built), `VALGRIND=0` (much faster), `TIMEOUT=10` to speed failures (or 100 if VALGRIND=1). - *gen.[ch] files are generated by the Makefile. - ccan/ is imported from ccan repo: PRs should go there, then `make update-ccan`. From aa074b4f357d5e38798ed406fcdabb6198eff59e Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:34:52 +0200 Subject: [PATCH 25/29] docs: fixing typoe on cln version in which the `dns` prefix has been added --- doc/lightningd-config.5.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/lightningd-config.5.md b/doc/lightningd-config.5.md index e8e67f476611..318d9bcff4b2 100644 --- a/doc/lightningd-config.5.md +++ b/doc/lightningd-config.5.md @@ -683,7 +683,7 @@ announced addresses are public (e.g. not localhost). This option can be used multiple times to add more addresses, and its use disables autolisten. - Since v23.058, the `dns:` prefix can be used to indicate that this hostname and port should be announced as a DNS hostname entry. Please note that most mainnet nodes do not yet use, read or propagate this information correctly. + Since v23.08, the `dns:` prefix can be used to indicate that this hostname and port should be announced as a DNS hostname entry. Please note that most mainnet nodes do not yet use, read or propagate this information correctly. * **announce-addr-dns**=*BOOL* (deprecated in v23.08) From 86bca8665cdb72b701d907b2e25c39e9c49928ed Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 10:52:42 +0200 Subject: [PATCH 26/29] docs: misc typoes fixed --- DEV.md | 2 +- .../coding-style-guidelines.md | 4 ++-- doc/contribute-to-core-lightning/release-checklist.md | 2 +- doc/developers-guide/deprecated-features.md | 2 +- doc/lightningd-config.5.md | 4 ++-- doc/lightningd-rpc.7.md | 8 ++++---- doc/lightningd.8.md | 2 +- doc/node-operators-guide/faq.md | 10 +++++----- doc/reckless.7.md | 8 ++++---- 9 files changed, 21 insertions(+), 21 deletions(-) diff --git a/DEV.md b/DEV.md index 291709cd223c..e28e9071cf45 100644 --- a/DEV.md +++ b/DEV.md @@ -7,7 +7,7 @@ - assert-based unit tests can "#include ../file.c", OR add objects to Makefile targets: `make update-mocks` will regenerate mocks for functions from link errors. - Commits should be reviewable, bisectable, and include tests. Pattern: one commit adds a python test with @pytest.mark.xfail(strict=True), next commit fixes the problem and removes that line. - Commits which fix crashes or bug MUST quote the bug for later searches: do not rely on being able to find the bug report in future! -- Commits which create signficant user (not developer!) visible changes should have Changelog-(Added|Deprecated|Changed|Fixed|EXPERIMENTAL) for assembling CHANGELOG.md at release time. +- Commits which create significant user (not developer!) visible changes should have Changelog-(Added|Deprecated|Changed|Fixed|EXPERIMENTAL) for assembling CHANGELOG.md at release time. - Deprecations must use the deprecation infrastructure, and append to the table in doc/developers-guide/deprecated-features.md - Adding a new JSON-RPC command requires the most careful design: start with doc/schemas/NAME.json and add doc/NAME.7 to MARKDOWNPAGES in doc/Makefile. `make doc-all` will regen the rest. - In pytest integration tests, name nodes l1, l2, etc in creation order. This matches the log prefixes they use (`lightningd-1` etc) and on test failure the logs and other ephemera will in /tmp/ltests-*/TESTNAME*/lightning-1/. diff --git a/doc/contribute-to-core-lightning/coding-style-guidelines.md b/doc/contribute-to-core-lightning/coding-style-guidelines.md index 3b5a04c4fce1..97a3b4f905e5 100644 --- a/doc/contribute-to-core-lightning/coding-style-guidelines.md +++ b/doc/contribute-to-core-lightning/coding-style-guidelines.md @@ -30,9 +30,9 @@ We have to stop somewhere. The two tools here are extracting deeply-indented co } ``` -## Tabs and indentaion +## Tabs and indentation -The C code uses TAB charaters with a visual indentation of 8 whitespaces. +The C code uses TAB characters with a visual indentation of 8 whitespaces. If you submit code for a review, make sure your editor knows this. When breaking a line with more than 80 characters, align parameters and arguments like so: diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md index 2a4ab6f0b5be..17aae99b60d1 100644 --- a/doc/contribute-to-core-lightning/release-checklist.md +++ b/doc/contribute-to-core-lightning/release-checklist.md @@ -20,7 +20,7 @@ Here's a checklist for the release process. 1. Make sure any `CHANGELOG.md` changes from point releases have been imported. 2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from https://github.com/settings/tokens -3. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness. +3. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all significant changes, and sub-ordered approximately by user impact & coolness. 4. Manually remove any entries which were mentioned for in the previous point releases (they will be duplicates!) 5. Create a new CHANGELOG.md heading to `vrc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this. 6. Update the package versions: `uv run make update-versions NEW_VERSION=vrc1` diff --git a/doc/developers-guide/deprecated-features.md b/doc/developers-guide/deprecated-features.md index 470fef6f88d9..3ef335a9c9a1 100644 --- a/doc/developers-guide/deprecated-features.md +++ b/doc/developers-guide/deprecated-features.md @@ -46,7 +46,7 @@ Types of deprecation: For each deprecation: 1. The deprecation is listed here, and in the CHANGELOG.md file. 2. We try to give at least 2 versions before removal. -3. Then one version where we issue a warning message if we detect a deprecated feature being used (not possible for deprecatred `Field` types). +3. Then one version where we issue a warning message if we detect a deprecated feature being used (not possible for deprecated `Field` types). 4. At least one version where the deprecated feature can be explicit re-enabled using `i-promise-to-fix-broken-api-user=FEATURENAME`. diff --git a/doc/lightningd-config.5.md b/doc/lightningd-config.5.md index 318d9bcff4b2..bc7b3c9faec1 100644 --- a/doc/lightningd-config.5.md +++ b/doc/lightningd-config.5.md @@ -491,7 +491,7 @@ have to do that. Normally HTLC onions which contain unknown even fields are rejected. This option specifies that this type is to be accepted, and ignored. Can be -specified multuple times. (Added in v23.08). +specified multiple times. (Added in v23.08). * **min-emergency-msat**=*msat* @@ -835,7 +835,7 @@ load plugins which have been disabled, using lightning-plugin(7) `start`. * **important-plugin**=*PLUGIN* - Speciy a plugin to run as part of Core Lightning. + Specify a plugin to run as part of Core Lightning. This can be specified multiple times to add multiple plugins. Plugins specified via this option are considered so important, that if the plugin stops for any reason (including via lightning-plugin(7) `stop`), diff --git a/doc/lightningd-rpc.7.md b/doc/lightningd-rpc.7.md index 018705b340ce..3de7fcd7cbb7 100644 --- a/doc/lightningd-rpc.7.md +++ b/doc/lightningd-rpc.7.md @@ -11,7 +11,7 @@ DESCRIPTION lightningd(8) communicates via RPC, especially JSONRPC over the UNIX domain socket (by default **$HOME/.lightning/bitcoin/lightning-rpc**, -but configuable with lightningd-config(5)). +but configurable with lightningd-config(5)). JSON WIRE FORMAT @@ -82,7 +82,7 @@ be added in future. You should safely ignore any unknown fields. Any field name which starts with "warning" is a specific warning, and should be documented in the commands' manual page. Each warning field -has an associated human-readable string, but it's redudant, as each +has an associated human-readable string, but it's redundant, as each separate warning should have a distinct field name (e.g. **warning\_offer\_unknown\_currency** and **warning\_offer\_missing\_description**). @@ -105,7 +105,7 @@ referred to in addition to simple JSON types: * `pubkey`: a 66-character `hex` which is an SEC-1 encoded secp256k1 point (usually used as a public key). * `msat`: a `u64` which indicates an amount of millisatoshis. Deprecated: may also be a string of the number, with "msat" appended. As an input parameter, lightningd(8) will accept strings with suffixes (see below). * `txid`: a 64-character `hex` Bitcoin transaction identifier. -* `signature`: a `hex` (144 bytes or less), which is a DER-encoded Bitcoin signature (without any sighash flags appended), +* `signature`: a `hex` (144 bytes or less), which is a DER-encoded Bitcoin signature (without any sighash flags appended), * `bip340sig`: a 128-character `hex` which is a BIP-340 (Schnorr) signature. * `point32`: a 64-character `hex` which represents an x-only pubkey. * `short_channel_id`: a string of form BLOCK "x" TXNUM "x" OUTNUM. @@ -250,7 +250,7 @@ Note: `"filter"` doesn't change the order, just which fields are printed. Any fields not explicitly mentioned are omitted from the output, but plugins which don't support filter (and some routines doing simple JSON transfers) may ignore `"filter"`, so you should treat -it as an optimazation only). +it as an optimization only). Note: if you specify an array where an object is specified or vice versa, the response may include a `warning_parameter_filter` field diff --git a/doc/lightningd.8.md b/doc/lightningd.8.md index 85c3717572ff..0a6eb64d12c5 100644 --- a/doc/lightningd.8.md +++ b/doc/lightningd.8.md @@ -121,7 +121,7 @@ which you can do by using dig(1) and querying *lseed.bitcoinstats.com*: This will give 25 IPv4 addresses, you can select any one of those. You will also need to learn the corresponding public key, which you can -determine by searching the IP addrss on [https://1ml.com/](https://1ml.com/) . The public +determine by searching the IP address on [https://1ml.com/](https://1ml.com/) . The public key is a long hex string, like so: *024772ee4fa461febcef09d5869e1238f932861f57be7a6633048514e3f56644a1*. (this example public key is not used as of this writing) diff --git a/doc/node-operators-guide/faq.md b/doc/node-operators-guide/faq.md index 17ad832d7174..44c6c1869b5c 100644 --- a/doc/node-operators-guide/faq.md +++ b/doc/node-operators-guide/faq.md @@ -65,10 +65,10 @@ Effort has been made to get `lightningd` running on Android, [see issue #3484](h ### How to forget about a channel? -> 🚧 -> +> 🚧 +> > Never use any `dev` command unless you know exactly what you are doing, and have checked with a developer that your understanding is correct. They are meant only as a means of last resort and have the potential to mess things up. You have been warned❗️ -> +> Channels may end up stuck during funding and never confirm on-chain. There is a variety of causes, the most common ones being that the funds have been double-spent, or the funding fee was too low to be confirmed. This is unlikely to happen in normal operation, as CLN tries to use sane defaults and prevents double-spends whenever possible, but using custom feerates or when the bitcoin backend has no good fee estimates it is still possible. @@ -86,7 +86,7 @@ lightning-cli withdraw $ADDR all This step is not required if the funding transaction was already double-spent, however it is safe to do it anyway, just in case. -Then wait for the transaction moving the funds to confirm. This ensures any pending funding transaction can no longer be confirmed. +Then wait for the transaction moving the funds to confirm. This ensures any pending funding transaction can no longer be confirmed. As an additional step you can also force-close the unconfirmed channel: @@ -159,7 +159,7 @@ There are 3 types of 'rescans' you can make: ### Database corruption / channel state lost -If you lose data (likely corrupted `lightningd.sqlite3`) about a channel **with `option_static_remotekey` enabled**, you can wait for your peer to unilateraly close the channel, then use `tools/lightning-hsmtool` with the `guesstoremote` command to attempt to recover your funds from the peer's published unilateral close transaction. +If you lose data (likely corrupted `lightningd.sqlite3`) about a channel **with `option_static_remotekey` enabled**, you can wait for your peer to unilaterally close the channel, then use `tools/lightning-hsmtool` with the `guesstoremote` command to attempt to recover your funds from the peer's published unilateral close transaction. If `option_static_remotekey` was not enabled, you're probably out of luck. The keys for your funds in your peer's unilateral close transaction are derived from information you lost. Fortunately, since version `0.7.3` channels are created with `option_static_remotekey` by default if your peer supports it. Which is to say that channels created after block [598000](https://blockstream.info/block/0000000000000000000dd93b8fb5c622b9c903bf6f921ef48e266f0ead7faedb) (short channel id starting with > 598000) have a high chance of supporting `option_static_remotekey`. You can verify it using the `features` field from the [`listpeers` command](ref:listpeers)'s result. diff --git a/doc/reckless.7.md b/doc/reckless.7.md index 49918023d56b..3fc5275cbe71 100644 --- a/doc/reckless.7.md +++ b/doc/reckless.7.md @@ -4,12 +4,12 @@ reckless -- Issue a command to the reckless plugin manager utility SYNOPSIS -------- -**reckless** *command* [*target/subcommand*] [*target*] +**reckless** *command* [*target/subcommand*] [*target*] DESCRIPTION ----------- -The **reckless** RPC starts a reckless process with the *command* and *target* provided. Node configuration, network, and lightning direrctory are automatically passed to the reckless utility. +The **reckless** RPC starts a reckless process with the *command* and *target* provided. Node configuration, network, and lightning directory are automatically passed to the reckless utility. - **command** (string) (one of "install", "uninstall", "search", "enable", "disable", "source", "--version"): Determines which command to pass to reckless - *command* **install** takes a *plugin\_name* to search for and install a named plugin. @@ -52,7 +52,7 @@ EXAMPLES -------- -**Example 1**: +**Example 1**: Request: ```shell @@ -86,7 +86,7 @@ Response: } ``` -**Example 2**: +**Example 2**: Request: ```shell From e0649598e762c850a02b3601ca3bb1500d9d9127 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 11:11:30 +0200 Subject: [PATCH 27/29] docs: fixing cross-ref --- doc/developers-guide/plugin-development.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers-guide/plugin-development.md b/doc/developers-guide/plugin-development.md index 3eb5ec8c443b..a647259d51d2 100644 --- a/doc/developers-guide/plugin-development.md +++ b/doc/developers-guide/plugin-development.md @@ -10,7 +10,7 @@ privacy: --- Plugins are a simple yet powerful way to extend the functionality provided by Core Lightning. They are subprocesses that are started by the main `lightningd` daemon and can interact with `lightningd` in a variety of ways: -- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to [`plugin start`][ref:plugin]. +- **[Command line option passthrough](doc:a-day-in-the-life-of-a-plugin)** allows plugins to register their own command line options that are exposed through `lightningd` so that only the main process needs to be configured. Option values are not remembered when a plugin is stopped or killed, but can be passed as parameters to rpc command [`plugin start`](ref:plugin). - **[JSON-RPC command passthrough](doc:json-rpc-passthrough)** adds a way for plugins to add their own commands to the JSON-RPC interface. - **[Event stream subscriptions](doc:event-notifications)** provide plugins with a push-based notification mechanism about events from the `lightningd`. - **[Hooks](doc:hooks)** are a primitive that allows plugins to be notified about internal events in `lightningd` and alter its behavior or inject custom behaviors. From 1b2bb4741196e3e8618d3651e924094452603180 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 11:12:07 +0200 Subject: [PATCH 28/29] docs: fixied word mismatch --- doc/node-operators-guide/plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/node-operators-guide/plugins.md b/doc/node-operators-guide/plugins.md index 1f2e37d9e7d2..8b050df2a96a 100644 --- a/doc/node-operators-guide/plugins.md +++ b/doc/node-operators-guide/plugins.md @@ -14,7 +14,7 @@ Power up your Core Lightning node and tailor it for your business needs with com > πŸ“˜ > -> Reckless currently supports both python and rust plugins only. Additional language support will be provided in future releases. For plugins built by the community in other languages, see the complete list of plugins [here](https://github.com/lightningd/plugins). +> Reckless currently supports python and rust plugins only. Additional language support will be provided in future releases. For plugins built by the community in other languages, see the complete list of plugins [here](https://github.com/lightningd/plugins). Typical plugin installation involves: finding the source plugin, copying, installing dependencies, testing, activating, and updating the lightningd config file. Reckless does all of these by invoking: From 5ecb21a3030c79e59e93a6e004727203531d22c0 Mon Sep 17 00:00:00 2001 From: enaples Date: Tue, 1 Sep 2026 11:13:18 +0200 Subject: [PATCH 29/29] docs: fixed link --- doc/developers-guide/plugin-development/additional-resources.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/developers-guide/plugin-development/additional-resources.md b/doc/developers-guide/plugin-development/additional-resources.md index 4904365e9a4d..53f2bb44862a 100644 --- a/doc/developers-guide/plugin-development/additional-resources.md +++ b/doc/developers-guide/plugin-development/additional-resources.md @@ -8,7 +8,7 @@ privacy: Check out a step-by-step recipe for building a simple `helloworld.py` example plugin based on [pyln-client](https://github.com/ElementsProject/lightning/tree/master/contrib/pyln-client). -πŸ¦‰ **[Write a hello-world plugin in Python](https://docs.corelightning.org/v1.0/recipes/write-a-hello-world-plugin-in-python)** +πŸ¦‰ **[Write a hello-world plugin in Python](https://docs.corelightning.org/recipes/write-a-hello-world-plugin-in-python)** You can also follow along the video below where Blockstream Engineer Rusty Russell walks you all the way from getting started with Core Lightning to building a plugin in Python.