mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 01:43:36 +01:00
Code Issues Projects Releases Wiki Activity

doc: update c-lightning to Core Lightning almost everywhere.

Browse Source 
Mostly comments and docs: some places are actually paths, which
I have avoided changing.  We may migrate them slowly, particularly
when they're user-visible.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2022-04-06 14:39:48 +09:30
parent 8c2f3ab5fe
commit 836c1b805b
56 changed files with 142 additions and 141 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
.github/workflows/ci.yaml vendored
View File

@ -71,7 +71,7 @@ jobs:
if-no-files-found: ignore if-no-files-found: ignore
check-dock: check-dock:
name: Check c-lightning doc name: Check core-lightning doc
runs-on: ubuntu-20.04 runs-on: ubuntu-20.04
env: env:
DEVELOPER: 1 DEVELOPER: 1

6
Dockerfile
View File

@ -1,7 +1,7 @@
# This dockerfile is meant to compile a c-lightning x64 image # This dockerfile is meant to compile a core-lightning x64 image
# It is using multi stage build: # It is using multi stage build:
# * downloader: Download litecoin/bitcoin and qemu binaries needed for c-lightning # * downloader: Download litecoin/bitcoin and qemu binaries needed for core-lightning
# * builder: Compile c-lightning dependencies, then c-lightning itself with static linking # * builder: Compile core-lightning dependencies, then c-lightning itself with static linking
# * final: Copy the binaries required at runtime # * final: Copy the binaries required at runtime
# The resulting image uploaded to dockerhub will only contain what is needed for runtime. # The resulting image uploaded to dockerhub will only contain what is needed for runtime.
# From the root of the repository, run "docker build -t yourimage:yourtag ." # From the root of the repository, run "docker build -t yourimage:yourtag ."

1
Makefile
View File

@ -17,6 +17,7 @@ SUPPRESS_OUTPUT :=
endif endif
DISTRO=$(shell lsb_release -is 2>/dev/null || echo unknown)-$(shell lsb_release -rs 2>/dev/null || echo unknown) DISTRO=$(shell lsb_release -is 2>/dev/null || echo unknown)-$(shell lsb_release -rs 2>/dev/null || echo unknown)
# Changing this could break installs!
PKGNAME = c-lightning PKGNAME = c-lightning
# We use our own internal ccan copy. # We use our own internal ccan copy.

16
README.md
View File

@ -1,6 +1,6 @@
# c-lightning: A specification compliant Lightning Network implementation in C # Core Lightning (CLN): A specification compliant Lightning Network implementation in C
c-lightning is a lightweight, highly customizable and [standard compliant][std] implementation of the Lightning Network protocol. Core Lightning (previously c-lightning) is a lightweight, highly customizable and [standard compliant][std] implementation of the Lightning Network protocol.
* [Getting Started](#getting-started) * [Getting Started](#getting-started)
* [Installation](#installation) * [Installation](#installation)
@ -32,7 +32,7 @@ Don't hesitate to reach out to us on IRC at [#lightning-dev @ libera.chat][irc1]
## Getting Started ## Getting Started
c-lightning only works on Linux and Mac OS, and 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`). Core Lightning only works on Linux and Mac OS, and 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](#pruning) for more details. Pruning (`prune=n` option in `bitcoin.conf`) is partially supported, see [here](#pruning) for more details.
### Installation ### Installation
@ -95,7 +95,7 @@ This creates a `.lightning/` subdirectory in your home directory: see `man -l do
### Using The JSON-RPC Interface ### Using The JSON-RPC Interface
c-lightning exposes a [JSON-RPC 2.0][jsonrpcspec] interface over a Unix Domain socket; the `lightning-cli` tool can be used to access it, or there is a [python client library](contrib/pyln-client). Core Lightning exposes a [JSON-RPC 2.0][jsonrpcspec] interface over a Unix Domain socket; the `lightning-cli` tool can be used to access it, or there is a [python client library](contrib/pyln-client).
You can use `lightning-cli help` to print a table of RPC methods; `lightning-cli help <command>` You can use `lightning-cli help` to print a table of RPC methods; `lightning-cli help <command>`
will offer specific information on that command. will offer specific information on that command.
@ -116,7 +116,7 @@ Once you've started for the first time, there's a script called
`contrib/bootstrap-node.sh` which will connect you to other nodes on `contrib/bootstrap-node.sh` which will connect you to other nodes on
the lightning network. the lightning network.
There are also numerous plugins available for c-lightning which add There are also numerous plugins available for Core Lightning which add
capabilities: in particular there's a collection at: capabilities: in particular there's a collection at:
https://github.com/lightningd/plugins https://github.com/lightningd/plugins
@ -206,11 +206,11 @@ To use a configuration file, create a file named `config` within your top-level
### Pruning ### Pruning
c-lightning requires JSON-RPC access to a fully synchronized `bitcoind` in order to synchronize with the Bitcoin network. Core Lightning requires JSON-RPC access to a fully synchronized `bitcoind` in order to synchronize with the Bitcoin network.
Access to ZeroMQ is not required and `bitcoind` does not need to be run with `txindex` like other implementations. Access to ZeroMQ is not required and `bitcoind` does not need to be run with `txindex` like other implementations.
The lightning daemon will poll `bitcoind` for new blocks that it hasn't processed yet, thus synchronizing itself with `bitcoind`. The lightning daemon will poll `bitcoind` for new blocks that it hasn't processed yet, thus synchronizing itself with `bitcoind`.
If `bitcoind` prunes a block that c-lightning has not processed yet, e.g., c-lightning was not running for a prolonged period, then `bitcoind` will not be able to serve the missing blocks, hence c-lightning will not be able to synchronize anymore and will be stuck. If `bitcoind` prunes a block that Core Lightning has not processed yet, e.g., Core Lightning was not running for a prolonged period, then `bitcoind` will not be able to serve the missing blocks, hence Core Lightning will not be able to synchronize anymore and will be stuck.
In order to avoid this situation you should be monitoring the gap between c-lightning's blockheight using `lightning-cli getinfo` and `bitcoind`'s blockheight using `bitcoin-cli getblockchaininfo`. In order to avoid this situation you should be monitoring the gap between Core Lightning's blockheight using `lightning-cli getinfo` and `bitcoind`'s blockheight using `bitcoin-cli getblockchaininfo`.
If the two blockheights drift apart it might be necessary to intervene. If the two blockheights drift apart it might be necessary to intervene.
### HD wallet encryption ### HD wallet encryption

2
action.yml
View File

@ -1,6 +1,6 @@
--- ---
name: 'Lightning CI' name: 'Lightning CI'
description: 'A preconfigured container with all c-lightning dependencies' description: 'A preconfigured container with all Core Lightning dependencies'
runs: runs:
using: 'docker' using: 'docker'
image: 'contrib/Dockerfile.tester' image: 'contrib/Dockerfile.tester'

2
bitcoin/psbt.h
View File

@ -92,7 +92,7 @@ bool psbt_finalize(struct wally_psbt *psbt);
*/ */
struct wally_tx *psbt_final_tx(const tal_t *ctx, const struct wally_psbt *psbt); struct wally_tx *psbt_final_tx(const tal_t *ctx, const struct wally_psbt *psbt);
/* psbt_make_key - Create a new, proprietary c-lightning key /* psbt_make_key - Create a new, proprietary Core Lightning key
* *
* @ctx - allocation context * @ctx - allocation context
* @key_subtype - type for this key * @key_subtype - type for this key

2
channeld/full_channel.c
View File

@ -462,7 +462,7 @@ static bool htlc_dust(const struct channel *channel,
* leads to the channel starving at the feast! This was reported by * leads to the channel starving at the feast! This was reported by
* ACINQ's @t-bast * ACINQ's @t-bast
* (https://github.com/lightningnetwork/lightning-rfc/issues/728) and * (https://github.com/lightningnetwork/lightning-rfc/issues/728) and
* demonstrated with c-lightning by @m-schmoock * demonstrated with Core Lightning by @m-schmoock
* (https://github.com/ElementsProject/lightning/pull/3498). * (https://github.com/ElementsProject/lightning/pull/3498).
* *
* To mostly avoid this situation, at least from our side, we apply an * To mostly avoid this situation, at least from our side, we apply an

2
cln-rpc/README.md
View File

@ -1,3 +1,3 @@
# `cln-rpc`: Talk to c-lightning # `cln-rpc`: Talk to Core Lightning

2
configure vendored
View File

@ -1,5 +1,5 @@
#! /bin/sh #! /bin/sh
# Simple configure script for c-lightning. # Simple configure script for Core Lightning.
set -e set -e

2
connectd/multiplex.c
View File

@ -519,7 +519,7 @@ static void handle_ping_reply(struct peer *peer, const u8 *msg)
status_peer_unusual(&peer->id, "Got malformed ping reply %s", status_peer_unusual(&peer->id, "Got malformed ping reply %s",
tal_hex(tmpctx, msg)); tal_hex(tmpctx, msg));
/* We print this because dev versions of c-lightning embed /* We print this because dev versions of Core Lightning embed
* version here: see check_ping_make_pong! */ * version here: see check_ping_make_pong! */
for (i = 0; i < tal_count(ignored); i++) { for (i = 0; i < tal_count(ignored); i++) {
if (ignored[i] < ' ' || ignored[i] == 127) if (ignored[i] < ' ' || ignored[i] == 127)

4
contrib/docker/linuxarm64v8.Dockerfile
View File

@ -1,7 +1,7 @@
# This dockerfile is meant to cross compile with a x64 machine for a arm64v8 host # This dockerfile is meant to cross compile with a x64 machine for a arm64v8 host
# It is using multi stage build: # It is using multi stage build:
# * downloader: Download litecoin/bitcoin and qemu binaries needed for c-lightning # * downloader: Download litecoin/bitcoin and qemu binaries needed for Core Lightning
# * builder: Cross compile c-lightning dependencies, then c-lightning itself with static linking # * builder: Cross compile Core Lightning dependencies, then Core Lightning itself with static linking
# * final: Copy the binaries required at runtime # * final: Copy the binaries required at runtime
# The resulting image uploaded to dockerhub will only contain what is needed for runtime. # The resulting image uploaded to dockerhub will only contain what is needed for runtime.
# From the root of the repository, run "docker build -t yourimage:yourtag -f contrib/linuxarm64v8.Dockerfile ." # From the root of the repository, run "docker build -t yourimage:yourtag -f contrib/linuxarm64v8.Dockerfile ."

4
contrib/pylightning/README.md
View File

@ -18,7 +18,7 @@ pip install pylightning
``` ```
Alternatively you can also install the development version to get access to Alternatively you can also install the development version to get access to
currently unreleased features by checking out the c-lightning source code and currently unreleased features by checking out the Core Lightning source code and
installing into your python3 environment: installing into your python3 environment:
```bash ```bash
@ -43,7 +43,7 @@ Generate invoice on one daemon and pay it on the other
from lightning import LightningRpc from lightning import LightningRpc
import random import random
# Create two instances of the LightningRpc object using two different c-lightning daemons on your computer # Create two instances of the LightningRpc object using two different Core Lightning daemons on your computer
l1 = LightningRpc("/tmp/lightning1/lightning-rpc") l1 = LightningRpc("/tmp/lightning1/lightning-rpc")
l5 = LightningRpc("/tmp/lightning5/lightning-rpc") l5 = LightningRpc("/tmp/lightning5/lightning-rpc")

4
contrib/pyln-client/README.md
View File

@ -15,7 +15,7 @@ pip install pyln-client
``` ```
Alternatively you can also install the development version to get access to Alternatively you can also install the development version to get access to
currently unreleased features by checking out the c-lightning source code and currently unreleased features by checking out the Core Lightning source code and
installing into your python3 environment: installing into your python3 environment:
```bash ```bash
@ -40,7 +40,7 @@ Generate invoice on one daemon and pay it on the other
from pyln.client import LightningRpc from pyln.client import LightningRpc
import random import random
# Create two instances of the LightningRpc object using two different c-lightning daemons on your computer # Create two instances of the LightningRpc object using two different Core Lightning daemons on your computer
l1 = LightningRpc("/tmp/lightning1/lightning-rpc") l1 = LightningRpc("/tmp/lightning1/lightning-rpc")
l5 = LightningRpc("/tmp/lightning5/lightning-rpc") l5 = LightningRpc("/tmp/lightning5/lightning-rpc")

2
contrib/pyln-client/pyproject.toml
View File

@ -1,7 +1,7 @@
[tool.poetry] [tool.poetry]
name = "pyln-client" name = "pyln-client"
version = "0.10.2.post1" version = "0.10.2.post1"
description = "Client library and plugin library for c-lightning" description = "Client library and plugin library for Core Lightning"
authors = ["Christian Decker <decker.christian@gmail.com>"] authors = ["Christian Decker <decker.christian@gmail.com>"]
license = "BSD-MIT" license = "BSD-MIT"
readme = "README.md" readme = "README.md"

2
contrib/pyln-proto/README.md
View File

@ -15,7 +15,7 @@ pip install pyln-proto
``` ```
Alternatively you can also install the development version to get access to Alternatively you can also install the development version to get access to
currently unreleased features by checking out the c-lightning source code and currently unreleased features by checking out the Core Lightning source code and
installing into your python3 environment: installing into your python3 environment:
```bash ```bash

2
contrib/pyln-proto/tests/test_onion.py
View File

@ -212,7 +212,7 @@ def sphinx_path_from_test_vector(filename: str) -> Tuple[onion.SphinxPath, dict]
def test_hop_params(): def test_hop_params():
"""Test that we generate the onion parameters correctly. """Test that we generate the onion parameters correctly.
Extracted from running the c-lightning implementation: Extracted from running the Core Lightning implementation:
```bash ```bash
devtools/onion runtest tests/vectors/onion-test-multi-frame.json devtools/onion runtest tests/vectors/onion-test-multi-frame.json

8
contrib/pyln-testing/README.md
View File

@ -1,11 +1,11 @@
# pyln-testing: A library to write tests against c-lightning # pyln-testing: A library to write tests against Core Lightning
This library implements a number of utilities that help building tests for This library implements a number of utilities that help building tests for
c-lightning nodes. In particular it provides a number of pytest fixtures that Core Lightning nodes. In particular it provides a number of pytest fixtures that
allow the management of a test network of a given topology and then execute a allow the management of a test network of a given topology and then execute a
test scenarion. test scenarion.
`pyln-testing` is used by c-lightning for its internal tests, and by the `pyln-testing` is used by Core Lightning for its internal tests, and by the
community plugin directory to exercise the plugins. community plugin directory to exercise the plugins.
## Installation ## Installation
@ -17,7 +17,7 @@ pip install pyln-testing
``` ```
Alternatively you can also install the development version to get access to Alternatively you can also install the development version to get access to
currently unreleased features by checking out the c-lightning source code and currently unreleased features by checking out the Core Lightning source code and
installing into your python3 environment: installing into your python3 environment:
```bash ```bash

2
contrib/pyln-testing/pyln/testing/utils.py
View File

@ -53,7 +53,7 @@ def env(name, default=None):
"""Access to environment variables """Access to environment variables
Allows access to environment variables, falling back to config.vars (part Allows access to environment variables, falling back to config.vars (part
of c-lightning's `./configure` output), and finally falling back to a of Core Lightning's `./configure` output), and finally falling back to a
default value. default value.
""" """

2
contrib/pyln-testing/pyproject.toml
View File

@ -1,7 +1,7 @@
[tool.poetry] [tool.poetry]
name = "pyln-testing" name = "pyln-testing"
version = "0.10.2" version = "0.10.2"
description = "Test your c-lightning integration, plugins or whatever you want" description = "Test your Core Lightning integration, plugins or whatever you want"
authors = ["Christian Decker <decker.christian@gmail.com>"] authors = ["Christian Decker <decker.christian@gmail.com>"]
license = "BSD-MIT" license = "BSD-MIT"
readme = "README.md" readme = "README.md"

8
doc/FAQ.md
View File

@ -71,7 +71,7 @@ Note that if you already have a channel open to them, you'll need to close it be
There is no risk to your channels if your IP address changes. There is no risk to your channels if your IP address changes.
Other nodes might not be able to connect to you, but your node can still connect to them. Other nodes might not be able to connect to you, but your node can still connect to them.
But c-lightning also has an integrated IPv4/6 address discovery mechanism. But Core Lightning also has an integrated IPv4/6 address discovery mechanism.
If your node detects an new public address, it will update its announcement. If your node detects an new public address, it will update its announcement.
For this to work binhind a NAT router you need to forward the TCP port 9735 to your node. For this to work binhind a NAT router you need to forward the TCP port 9735 to your node.
@ -91,7 +91,7 @@ If you use a single `bitcoind` for multiple `lightningd`'s, be sure to raise the
max RPC thread limit (`-rpcthreads`), each `lightningd` can use up to 4 threads, which is max RPC thread limit (`-rpcthreads`), each `lightningd` can use up to 4 threads, which is
the default `bitcoind` max. the default `bitcoind` max.
### Can I use C-lightning on mobile ? ### Can I use Core Lightning on mobile ?
#### Remote control #### Remote control
@ -113,7 +113,7 @@ In summary: as a Bitcoin user, one may be familiar with a file or a seed
(or some mnemonics) from which (or some mnemonics) from which
it can recover all its funds. it can recover all its funds.
C-lightning has an internal bitcoin wallet, which you can use to make "on-chain" Core Lightning has an internal bitcoin wallet, which you can use to make "on-chain"
transactions, (see [withdraw](https://lightning.readthedocs.io/lightning-withdraw.7.html). transactions, (see [withdraw](https://lightning.readthedocs.io/lightning-withdraw.7.html).
These on-chain funds are backed up via the HD wallet seed, stored in byte-form in `hsm_secret`. These on-chain funds are backed up via the HD wallet seed, stored in byte-form in `hsm_secret`.
@ -137,7 +137,7 @@ Tools for replication are currently in active development, using the `db_write`
There are 3 types of 'rescans' you can make: There are 3 types of 'rescans' you can make:
- `rescanblockchain`: A `bitcoind` RPC call which rescans the blockchain - `rescanblockchain`: A `bitcoind` RPC call which rescans the blockchain
starting at the given height. This does not have an effect on c-lightning starting at the given height. This does not have an effect on Core Lightning
as `lightningd` tracks all block and wallet data independently. as `lightningd` tracks all block and wallet data independently.
- `--rescan=depth`: A `lightningd` configuration flag. This flag is read at node startup - `--rescan=depth`: A `lightningd` configuration flag. This flag is read at node startup
and tells lightningd at what depth from current blockheight to rebuild its internal state. and tells lightningd at what depth from current blockheight to rebuild its internal state.

4
doc/HACKING.md
View File

@ -91,7 +91,7 @@ Here's a list of parts, with notes:
Debugging Debugging
--------- ---------
You can build c-lightning with DEVELOPER=1 to use dev commands listed in You can build Core Lightning with DEVELOPER=1 to use dev commands listed in
``cli/lightning-cli help``. ``./configure --enable-developer`` will do that. ``cli/lightning-cli help``. ``./configure --enable-developer`` will do that.
You can log console messages with log_info() in lightningd and status_debug() You can log console messages with log_info() in lightningd and status_debug()
in other subdaemons. in other subdaemons.
@ -110,7 +110,7 @@ subdaemon will be stopped (it sends itself a SIGSTOP); you'll need to
Database Database
-------- --------
c-lightning state is persisted in `lightning-dir`. Core Lightning state is persisted in `lightning-dir`.
It is a sqlite database stored in the `lightningd.sqlite3` file, typically It is a sqlite database stored in the `lightningd.sqlite3` file, typically
under `~/.lightning/<network>/`. under `~/.lightning/<network>/`.
You can run queries against this file like so: You can run queries against this file like so:

8
doc/INSTALL.md
View File

@ -138,7 +138,7 @@ To Build on FreeBSD
OS version: FreeBSD 11.1-RELEASE or above OS version: FreeBSD 11.1-RELEASE or above
c-lightning is in the FreeBSD ports, so install it as any other port Core Lightning is in the FreeBSD ports, so install it as any other port
(dependencies are handled automatically): (dependencies are handled automatically):
# pkg install c-lightning # pkg install c-lightning
@ -285,7 +285,7 @@ To cross-compile for Android
Make a standalone toolchain as per Make a standalone toolchain as per
https://developer.android.com/ndk/guides/standalone_toolchain.html. https://developer.android.com/ndk/guides/standalone_toolchain.html.
For c-lightning you must target an API level of 24 or higher. For Core Lightning you must target an API level of 24 or higher.
Depending on your toolchain location and target arch, source env variables Depending on your toolchain location and target arch, source env variables
such as: such as:
@ -370,7 +370,7 @@ Download and build gmp:
make make
make install make install
Then, build c-lightning with the following commands: Then, build Core Lightning with the following commands:
./configure ./configure
make make
@ -381,7 +381,7 @@ For all the other Pi devices out there, consider using [Armbian](https://www.arm
You can compile in `customize-image.sh` using the instructions for Ubuntu. You can compile in `customize-image.sh` using the instructions for Ubuntu.
A working example that compiles both bitcoind and c-lightning for Armbian can A working example that compiles both bitcoind and Core Lightning for Armbian can
be found [here](https://github.com/Sjors/armbian-bitcoin-core). be found [here](https://github.com/Sjors/armbian-bitcoin-core).
To compile for Alpine To compile for Alpine

12
doc/PLUGINS.md
View File

@ -1,7 +1,7 @@
# Plugins # Plugins
Plugins are a simple yet powerful way to extend the functionality Plugins are a simple yet powerful way to extend the functionality
provided by c-lightning. They are subprocesses that are started by the provided by Core Lightning. They are subprocesses that are started by the
main `lightningd` daemon and can interact with `lightningd` in a main `lightningd` daemon and can interact with `lightningd` in a
variety of ways: variety of ways:
@ -873,7 +873,7 @@ rely on the shutdown notification always been send.
## Hooks ## Hooks
Hooks allow a plugin to define custom behavior for `lightningd` Hooks allow a plugin to define custom behavior for `lightningd`
without having to modify the c-lightning source code itself. A plugin without having to modify the Core Lightning source code itself. A plugin
declares that it'd like to be consulted on what to do next for certain declares that it'd like to be consulted on what to do next for certain
events in the daemon. A hook can then decide how `lightningd` should events in the daemon. A hook can then decide how `lightningd` should
react to the given event. react to the given event.
@ -1555,7 +1555,7 @@ The `custommsg` plugin hook is the receiving counterpart to the
[`sendcustommsg`][sendcustommsg] RPC method and allows plugins to handle [`sendcustommsg`][sendcustommsg] RPC method and allows plugins to handle
messages that are not handled internally. The goal of these two components is messages that are not handled internally. The goal of these two components is
to allow the implementation of custom protocols or prototypes on top of a to allow the implementation of custom protocols or prototypes on top of a
c-lightning node, without having to change the node's implementation itself. Core Lightning node, without having to change the node's implementation itself.
The payload for a call follows this format: The payload for a call follows this format:
@ -1569,12 +1569,12 @@ The payload for a call follows this format:
This payload would have been sent by the peer with the `node_id` matching This payload would have been sent by the peer with the `node_id` matching
`peer_id`, and the message has type `0x1337` and contents `ffffffff`. Notice `peer_id`, and the message has type `0x1337` and contents `ffffffff`. Notice
that the messages are currently limited to odd-numbered types and must not that the messages are currently limited to odd-numbered types and must not
match a type that is handled internally by c-lightning. These limitations are match a type that is handled internally by Core Lightning. These limitations are
in place in order to avoid conflicts with the internal state tracking, and in place in order to avoid conflicts with the internal state tracking, and
avoiding disconnections or channel closures, since odd-numbered message can be avoiding disconnections or channel closures, since odd-numbered message can be
ignored by nodes (see ["it's ok to be odd" in the specification][oddok] for ignored by nodes (see ["it's ok to be odd" in the specification][oddok] for
details). The plugin must implement the parsing of the message, including the details). The plugin must implement the parsing of the message, including the
type prefix, since c-lightning does not know how to parse the message. type prefix, since Core Lightning does not know how to parse the message.
Because this is a chained hook, the daemon expects the result to be Because this is a chained hook, the daemon expects the result to be
`{'result': 'continue'}`. It will fail if something else is returned. `{'result': 'continue'}`. It will fail if something else is returned.
@ -1625,7 +1625,7 @@ will cause the message not to be handed to any other hooks.
## Bitcoin backend ## Bitcoin backend
C-lightning communicates with the Bitcoin network through a plugin. It uses the Core Lightning communicates with the Bitcoin network through a plugin. It uses the
`bcli` plugin by default but you can use a custom one, multiple custom ones for `bcli` plugin by default but you can use a custom one, multiple custom ones for
different operations, or write your own for your favourite Bitcoin data source! different operations, or write your own for your favourite Bitcoin data source!

8
doc/REPRODUCIBLE.md
View File

@ -1,6 +1,6 @@
# Reproducible builds for c-lightning # Reproducible builds for Core Lightning
This document describes the steps involved to build c-lightning in a This document describes the steps involved to build Core Lightning in a
reproducible way. Reproducible builds close the final gap in the lifecycle of reproducible way. Reproducible builds close the final gap in the lifecycle of
open-source projects by allowing maintainers to verify and certify that a open-source projects by allowing maintainers to verify and certify that a
given binary was indeed produced by compiling an unmodified version of the given binary was indeed produced by compiling an unmodified version of the
@ -8,7 +8,7 @@ publicly available source. In particular the maintainer certifies that the
binary corresponds a) to the exact version of the and b) that no malicious binary corresponds a) to the exact version of the and b) that no malicious
changes have been applied before or after the compilation. changes have been applied before or after the compilation.
c-lightning has provided a manifest of the binaries included in a release, Core Lightning has provided a manifest of the binaries included in a release,
along with signatures from the maintainers since version 0.6.2. along with signatures from the maintainers since version 0.6.2.
The steps involved in creating reproducible builds are: The steps involved in creating reproducible builds are:
@ -109,7 +109,7 @@ DISTRIB_DESCRIPTION="Ubuntu 18.04 LTS"
## Builder image setup ## Builder image setup
Once we have the clean base image we need to customize it to be able to build Once we have the clean base image we need to customize it to be able to build
c-lightning. This includes disabling the update repositories, downloading the Core Lightning. This includes disabling the update repositories, downloading the
build dependencies and specifying the steps required to perform the build. build dependencies and specifying the steps required to perform the build.
For this purpose we have a number of Dockerfiles in the For this purpose we have a number of Dockerfiles in the

2
doc/STYLE.md
View File

@ -218,7 +218,7 @@ cautiously as too many parameters get unwieldy quickly.
## Github Workflows ## Github Workflows
We have adopted a number of workflows to facilitate the development of We have adopted a number of workflows to facilitate the development of
c-lightning, and to make things more pleasant for contributors. Core Lightning, and to make things more pleasant for contributors.
### Changelog Entries in Commit Messages ### Changelog Entries in Commit Messages

72
doc/TOR.md
View File

@ -1,6 +1,6 @@
# Setting up TOR with c-lightning # Setting up TOR with Core Lightning
To use any Tor features with c-lightning you must have Tor installed and running. To use any Tor features with Core Lightning you must have Tor installed and running.
Note that we only support Tor v3: you can check your installed Tor version with `tor --version` or `sudo tor --version` Note that we only support Tor v3: you can check your installed Tor version with `tor --version` or `sudo tor --version`
@ -19,13 +19,13 @@ just check that this line is present in the Tor config file `/etc/tor/torrc`:
`ExitPolicy reject *:* # no exits allowed` `ExitPolicy reject *:* # no exits allowed`
This does not affect c-lightning connect, listen, etc.. This does not affect Core Lightning connect, listen, etc..
It will only prevent your node from becoming a Tor exit node. It will only prevent your node from becoming a Tor exit node.
Only enable this if you are sure about the implications. Only enable this if you are sure about the implications.
If you don't want to create .onion addresses this should be enough. If you don't want to create .onion addresses this should be enough.
There are several ways by which a c-lightning node can accept or make connections over Tor. There are several ways by which a Core Lightning node can accept or make connections over Tor.
The node can be reached over Tor by connecting to its .onion address. The node can be reached over Tor by connecting to its .onion address.
@ -47,7 +47,7 @@ Tor provides NAT-traversal for free, so even if you or your ISP has a complex
network between you and the Internet, as long as you can use Tor you can network between you and the Internet, as long as you can use Tor you can
be connected to. be connected to.
Note: c-lightning also support IPv4/6 address discovery behind NAT routers. Note: Core Lightning also support IPv4/6 address discovery behind NAT routers.
For this to work you need to forward the TCP port 9735 to your node. For this to work you need to forward the TCP port 9735 to your node.
In this case you don't need TOR to punch through your firewall. In this case you don't need TOR to punch through your firewall.
This usually has the benefit of quicker and more stable connections but does not This usually has the benefit of quicker and more stable connections but does not
@ -113,12 +113,12 @@ the user that will run `lightningd` and check this command:
cat /run/tor/control.authcookie > /dev/null cat /run/tor/control.authcookie > /dev/null
``` ```
If the above prints nothing and returns, then C-Lightning "should" work If the above prints nothing and returns, then Core Lightning "should" work
with your Tor. with your Tor.
If it prints an error, some configuration problem will likely prevent If it prints an error, some configuration problem will likely prevent
C-Lightning from working with your Tor. Core Lightning from working with your Tor.
Then make sure these are in your `${LIGHTNING_DIR}/config` or other C-Lightning configuration Then make sure these are in your `${LIGHTNING_DIR}/config` or other Core Lightning configuration
(or prepend `--` to each of them and add them to your `lightningd` invocation (or prepend `--` to each of them and add them to your `lightningd` invocation
command line): command line):
@ -129,25 +129,25 @@ addr=statictor:127.0.0.1:9051
always-use-proxy=true always-use-proxy=true
``` ```
1. `proxy` informs C-Lightning that you have a SOCKS5 proxy at port 9050. 1. `proxy` informs Core Lightning that you have a SOCKS5 proxy at port 9050.
C-Lightning will assume that this is a Tor proxy, port 9050 is the Core Lightning will assume that this is a Tor proxy, port 9050 is the
default in most Linux distributions; you can double-check `/etc/tor/torrc` default in most Linux distributions; you can double-check `/etc/tor/torrc`
for a `SocksPort` entry to confirm the port number. for a `SocksPort` entry to confirm the port number.
2. `bind-addr` informs C-Lightning to bind itself to port 9735. 2. `bind-addr` informs Core Lightning to bind itself to port 9735.
This is needed for the subsequent `statictor` to work. This is needed for the subsequent `statictor` to work.
9735 is the normal Lightning Network port, so this setting may already be present. 9735 is the normal Lightning Network port, so this setting may already be present.
If you add a second `bind-addr=...` you may get errors, so choose this new one If you add a second `bind-addr=...` you may get errors, so choose this new one
or keep the old one, but don't keep both. or keep the old one, but don't keep both.
This has to appear before any `statictor:` setting. This has to appear before any `statictor:` setting.
3. `addr=statictor:` informs C-Lightning that you want to create a persistent 3. `addr=statictor:` informs Core Lightning that you want to create a persistent
hidden service that is based on your node private key. hidden service that is based on your node private key.
This informs C-Lightning as well that the Tor Control Port is 9051. This informs Core Lightning as well that the Tor Control Port is 9051.
You can also use `bind-addr=statictor:` instead to not announce the You can also use `bind-addr=statictor:` instead to not announce the
persistent hidden service, but if anyone wants to make a channel with persistent hidden service, but if anyone wants to make a channel with
you, you either have to connect to them, or you have to reveal your you, you either have to connect to them, or you have to reveal your
address to them explicitly (i.e. autopilots and the like will likely address to them explicitly (i.e. autopilots and the like will likely
never connect to you). never connect to you).
4. `always-use-proxy` informs C-Lightning to always use Tor even when 4. `always-use-proxy` informs Core Lightning to always use Tor even when
connecting to nodes with public IPs. connecting to nodes with public IPs.
You can set this to `false` or remove it, You can set this to `false` or remove it,
if you are not privacy-conscious **and** find Tor is too slow for you. if you are not privacy-conscious **and** find Tor is too slow for you.
@ -162,7 +162,7 @@ Tor Browser will run a built-in Tor instance, but with the proxy at port
port at 9051). port at 9051).
The mobile Orbot uses the same defaults as Tor Browser (9150 and 9151). The mobile Orbot uses the same defaults as Tor Browser (9150 and 9151).
You can then use these settings for C-Lightning: You can then use these settings for Core Lightning:
``` ```
proxy=127.0.0.1:9150 proxy=127.0.0.1:9150
@ -171,30 +171,30 @@ addr=statictor:127.0.0.1:9151
always-use-proxy=true always-use-proxy=true
``` ```
You will have to run C-Lightning after launching Tor Browser or Orbot, You will have to run Core Lightning after launching Tor Browser or Orbot,
and keep Tor Browser or Orbot open as long as C-Lightning is running, and keep Tor Browser or Orbot open as long as Core Lightning is running,
but this is a setup which allows others to connect and fund channels but this is a setup which allows others to connect and fund channels
to you, anywhere (no port forwarding! works wherever Tor works!), and to you, anywhere (no port forwarding! works wherever Tor works!), and
you do not have to do anything more complicated than download and you do not have to do anything more complicated than download and
install Tor Browser. install Tor Browser.
This may be useful for operating system distributions that do not have This may be useful for operating system distributions that do not have
Tor in their repositories, assuming we can ever get C-Lightning running Tor in their repositories, assuming we can ever get Core Lightning running
on those. on those.
### Detailed Discussion ### Detailed Discussion
#### Three Ways to Create .onion Addresses for C-lightning #### Three Ways to Create .onion Addresses for Core Lightning
You have have Tor create an onion address for you, and tell You have have Tor create an onion address for you, and tell
c-lightning to use that, or you can have c-lightning tell Tor to Core Lightning to use that, or you can have Core Lightning tell Tor to
create the same onion address every time it starts up, or you can have create the same onion address every time it starts up, or you can have
c-lightning tell Tor to create a new onion address every time. Core Lightning tell Tor to create a new onion address every time.
#### Tor-Created .onion Address #### Tor-Created .onion Address
Having Tor create an onion address lets you run other services (e.g. Having Tor create an onion address lets you run other services (e.g.
a web server) at that same address, and you just tell that address to a web server) at that same address, and you just tell that address to
c-lightning and it doesn't have to talk to the Tor server at all. Core Lightning and it doesn't have to talk to the Tor server at all.
Put the following in your `/etc/tor/torrc` file: Put the following in your `/etc/tor/torrc` file:
@ -218,14 +218,14 @@ You will find the newly created address (myaddress.onion) with:
sudo cat /var/lib/tor/lightningd-service_v3/hostname sudo cat /var/lib/tor/lightningd-service_v3/hostname
``` ```
Now you need to tell c-lightning to advertize that onion hostname and Now you need to tell Core Lightning to advertize that onion hostname and
port, by placing `announce-addr=myaddress.onion` in your lightning port, by placing `announce-addr=myaddress.onion` in your lightning
config. config.
#### Letting C-lightning Control Tor #### Letting Core Lightning Control Tor
To have c-lightning control your Tor addresses, you have to tell Tor To have Core Lightning control your Tor addresses, you have to tell Tor
to accept control commands from c-lightning, either by using a cookie, to accept control commands from Core Lightning, either by using a cookie,
or a password. or a password.
##### Service authenticated by cookie ##### Service authenticated by cookie
@ -269,7 +269,7 @@ Save the file and restart the Tor service.
Put `tor-service-password=yourpassword` (not the hash) in your Put `tor-service-password=yourpassword` (not the hash) in your
lightning configuration file. lightning configuration file.
##### C-Lightning Creating Persistent Hidden Addresses ##### Core Lightning Creating Persistent Hidden Addresses
This is usually better than transient addresses, as nodes won't have This is usually better than transient addresses, as nodes won't have
to wait for gossip propagation to find out your new address each time to wait for gossip propagation to find out your new address each time
@ -281,7 +281,7 @@ to add *two* lines in your lightningd config file:
1. A local address which lightningd can tell Tor to connect to when 1. A local address which lightningd can tell Tor to connect to when
connections come in, e.g. `bind-addr=127.0.0.1:9735`. connections come in, e.g. `bind-addr=127.0.0.1:9735`.
2. After that, a `addr=statictor:127.0.0.1:9051` to tell 2. After that, a `addr=statictor:127.0.0.1:9051` to tell
c-lightning to set up and announce a Tor onion address (and tell Core Lightning to set up and announce a Tor onion address (and tell
Tor to send connections to our real address, above). Tor to send connections to our real address, above).
You can use `bind-addr` if you want to set up the onion address and You can use `bind-addr` if you want to set up the onion address and
@ -303,9 +303,9 @@ for fresh gossip messages if you announce it, before they can connect.
| ------- | ------------- | ------------------------- |------------------------- | ------- | ------------- | ------------------------- |-------------------------
| 1 | Public | NO | Outgoing | | 1 | Public | NO | Outgoing |
| 2 | Public | FIXED BY TOR | Incoming [1] | | 2 | Public | FIXED BY TOR | Incoming [1] |
| 3 | Public | FIXED BY C-LIGHTNING | Incoming [1] | | 3 | Public | FIXED BY CORE LIGHTNING | Incoming [1] |
| 4 | Not Announced | FIXED BY TOR | Incoming [1] | | 4 | Not Announced | FIXED BY TOR | Incoming [1] |
| 5 | Not Announced | FIXED BY C-LIGHTNING | Incoming [1] | | 5 | Not Announced | FIXED BY CORE LIGHTNING | Incoming [1] |
NOTE: NOTE:
@ -362,7 +362,7 @@ If they match you can use the `--addr` command line option.
Other nodes can connect to you entirely over Tor, and the Tor address Other nodes can connect to you entirely over Tor, and the Tor address
doesn't change every time you restart. doesn't change every time you restart.
You simply tell c-lightning to advertize both addresses (you can use You simply tell Core Lightning to advertize both addresses (you can use
`sudo cat /var/lib/tor/lightningd-service_v3/hostname` to get your `sudo cat /var/lib/tor/lightningd-service_v3/hostname` to get your
Tor-assigned onion address). Tor-assigned onion address).
@ -380,12 +380,12 @@ addr=yourIPAddress:port
announce-addr=your.onionAddress:port announce-addr=your.onionAddress:port
``` ```
#### Case #3: Public IP address, and a fixed Tor address set by C-lightning #### Case #3: Public IP address, and a fixed Tor address set by Core Lightning
Other nodes can connect to you entirely over Tor, and the Tor address Other nodes can connect to you entirely over Tor, and the Tor address
doesn't change every time you restart. doesn't change every time you restart.
See "Letting C-lightning Control Tor" for how to get c-lightning See "Letting Core Lightning Control Tor" for how to get Core Lightning
talking to Tor. talking to Tor.
If you have an internal IP address: If you have an internal IP address:
@ -406,7 +406,7 @@ addr=statictor:127.0.0.1:9051
Other nodes can only connect to you over Tor. Other nodes can only connect to you over Tor.
You simply tell c-lightning to advertize the Tor address (you can use You simply tell Core Lightning to advertize the Tor address (you can use
`sudo cat /var/lib/tor/lightningd-service_v3/hostname` to get your `sudo cat /var/lib/tor/lightningd-service_v3/hostname` to get your
Tor-assigned onion address). Tor-assigned onion address).
@ -416,11 +416,11 @@ proxy=127.0.0.1:9050
always-use-proxy=true always-use-proxy=true
``` ```
#### Case #4: Unannounced IP address, and a fixed Tor address set by C-lightning #### Case #4: Unannounced IP address, and a fixed Tor address set by Core Lightning
Other nodes can only connect to you over Tor. Other nodes can only connect to you over Tor.
See "Letting C-lightning Control Tor" for how to get c-lightning See "Letting Core Lightning Control Tor" for how to get Core Lightning
talking to Tor. talking to Tor.
``` ```

4
doc/conf.py
View File

@ -59,7 +59,7 @@ master_doc = 'index'
# General information about the project. # General information about the project.
project = 'c-lightning' project = 'c-lightning'
author = 'c-lightning Developers' author = 'Core Lightning Developers'
copyright = datetime.now().strftime('2015 — %Y, {}'.format(author)) copyright = datetime.now().strftime('2015 — %Y, {}'.format(author))
# The version info for the project you're documenting, acts as replacement for # The version info for the project you're documenting, acts as replacement for
@ -143,7 +143,7 @@ html_theme = 'sphinx_rtd_theme'
# The name for this set of Sphinx documents. # The name for this set of Sphinx documents.
# "<project> v<release> documentation" by default. # "<project> v<release> documentation" by default.
# #
html_title = 'c-lightning ' + version html_title = 'Core Lightning ' + version
# A shorter title for the navigation bar. Default is the same as html_title. # A shorter title for the navigation bar. Default is the same as html_title.
# #

4
doc/index.rst
View File

@ -1,5 +1,5 @@
c-lightning Documentation Core Lightning Documentation
========================= ============================
.. toctree:: .. toctree::
:maxdepth: 1 :maxdepth: 1

2
doc/lightning-close.7.md
View File

@ -26,7 +26,7 @@ indefinitely until the peer is online and can negotiate a mutual close.
The default is 2 days (172800 seconds). The default is 2 days (172800 seconds).
The *destination* can be of any Bitcoin bech32 type. The *destination* can be of any Bitcoin bech32 type.
If it isn't specified, the default is a c-lightning wallet address. If If it isn't specified, the default is a Core Lightning wallet address. If
the peer hasn't offered the `option_shutdown_anysegwit` feature, then the peer hasn't offered the `option_shutdown_anysegwit` feature, then
taproot addresses (or other v1+ segwit) are not allowed. Tell your taproot addresses (or other v1+ segwit) are not allowed. Tell your
friends to upgrade! friends to upgrade!

2
doc/lightning-createonion.7.md
View File

@ -11,7 +11,7 @@ DESCRIPTION
The **createonion** RPC command allows the caller to create a custom onion The **createonion** RPC command allows the caller to create a custom onion
with custom payloads at each hop in the route. A custom onion can be used to with custom payloads at each hop in the route. A custom onion can be used to
implement protocol extensions that are not supported by c-lightning directly. implement protocol extensions that are not supported by Core Lightning directly.
The *hops* parameter is a JSON list of dicts, each specifying a node and the The *hops* parameter is a JSON list of dicts, each specifying a node and the
payload destined for that node. The following is an example of a 3 hop onion: payload destined for that node. The following is an example of a 3 hop onion:

2
doc/lightning-datastore.7.md
View File

@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **datastore** RPC command allows plugins to store data in the The **datastore** RPC command allows plugins to store data in the
c-lightning database, for later retrieval. Core Lightning database, for later retrieval.
*key* is an array of values (though a single value is treated as a *key* is an array of values (though a single value is treated as a
one-element array), to form a hierarchy. Using the first element of one-element array), to form a hierarchy. Using the first element of

2
doc/lightning-deldatastore.7.md
View File

@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **deldatastore** RPC command allows plugins to delete data it has The **deldatastore** RPC command allows plugins to delete data it has
stored in the c-lightning database. stored in the Core Lightning database.
The command fails if the *key* isn't present, or if *generation* The command fails if the *key* isn't present, or if *generation*
is specified and the generation of the data does not exactly match. is specified and the generation of the data does not exactly match.

2
doc/lightning-getinfo.7.md
View File

@ -1,4 +1,4 @@
lightning-getinfo -- Command to receive all information about the c-lightning node. lightning-getinfo -- Command to receive all information about the Core Lightning node.
============================================================ ============================================================
SYNOPSIS SYNOPSIS

2
doc/lightning-listdatastore.7.md
View File

@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **listdatastore** RPC command allows plugins to fetch data which was The **listdatastore** RPC command allows plugins to fetch data which was
stored in the c-lightning database. stored in the Core Lightning database.
All immediate children of the *key* (or root children) are returned: All immediate children of the *key* (or root children) are returned:
a *key* with children won't have a *hex* or *generation* entry. a *key* with children won't have a *hex* or *generation* entry.

2
doc/lightning-listforwards.7.md
View File

@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **listforwards** RPC command displays all htlcs that have been The **listforwards** RPC command displays all htlcs that have been
attempted to be forwarded by the c-lightning node. attempted to be forwarded by the Core Lightning node.
If *status* is specified, then only the forwards with the given status are returned. If *status* is specified, then only the forwards with the given status are returned.
*status* can be either *offered* or *settled* or *failed* or *local_failed* *status* can be either *offered* or *settled* or *failed* or *local_failed*

2
doc/lightning-listfunds.7.md
View File

@ -1,4 +1,4 @@
lightning-listfunds -- Command showing all funds currently managed by the c-lightning node lightning-listfunds -- Command showing all funds currently managed by the Core Lightning node
========================================================================================== ==========================================================================================
SYNOPSIS SYNOPSIS

4
doc/lightning-multifundchannel.7.md
View File

@ -15,7 +15,7 @@ that is shared by all channels.
If not already connected, **multifundchannel** will automatically attempt If not already connected, **multifundchannel** will automatically attempt
to connect; you may provide a *@host:port* hint appended to the node ID to connect; you may provide a *@host:port* hint appended to the node ID
so that c-lightning can learn how to connect to the node; so that Core Lightning can learn how to connect to the node;
see lightning-connect(7). see lightning-connect(7).
Once the transaction is confirmed, normal channel operations may begin. Once the transaction is confirmed, normal channel operations may begin.
@ -134,7 +134,7 @@ the channel funding process will cancel the funding locally, but
the peer thinks the channel is already waiting for funding lockin. the peer thinks the channel is already waiting for funding lockin.
In that case, the next time we connect to the peer, our node will In that case, the next time we connect to the peer, our node will
tell the peer to forget the channel, but some nodes (in particular, tell the peer to forget the channel, but some nodes (in particular,
c-lightning nodes) will disconnect when our node tells them to Core Lightning nodes) will disconnect when our node tells them to
forget the channel. forget the channel.
If you immediately **multifundchannel** with that peer, it could If you immediately **multifundchannel** with that peer, it could
trigger this connect-forget-disconnect behavior, causing the trigger this connect-forget-disconnect behavior, causing the

2
doc/lightning-multiwithdraw.7.md
View File

@ -9,7 +9,7 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
The **multiwithdraw** RPC command sends funds from c-lightning's internal The **multiwithdraw** RPC command sends funds from Core Lightning's internal
wallet to the addresses specified in *outputs*, wallet to the addresses specified in *outputs*,
which is an array containing objects of the form `{address: amount}`. which is an array containing objects of the form `{address: amount}`.
The `amount` may be the string *"all"*, indicating that all onchain funds The `amount` may be the string *"all"*, indicating that all onchain funds

6
doc/lightning-newaddr.7.md
View File

@ -1,5 +1,5 @@
lightning-newaddr -- Command for generating a new address to be used by c-lightning lightning-newaddr -- Command for generating a new address to be used by Core Lightning
=================================================================================== ======================================================================================
SYNOPSIS SYNOPSIS
-------- --------
@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **newaddr** RPC command generates a new address which can The **newaddr** RPC command generates a new address which can
subsequently be used to fund channels managed by the c-lightning node. subsequently be used to fund channels managed by the Core Lightning node.
The funding transaction needs to be confirmed before funds can be used. The funding transaction needs to be confirmed before funds can be used.

2
doc/lightning-sendcustommsg.7.md
View File

@ -20,7 +20,7 @@ method. The messages must not use even-numbered types, since these may require
synchronous handling on the receiving side, and can cause the connection to be synchronous handling on the receiving side, and can cause the connection to be
dropped. The message types may also not use one of the internally handled dropped. The message types may also not use one of the internally handled
types, since that may cause issues with the internal state tracking of types, since that may cause issues with the internal state tracking of
c-lightning. Core Lightning.
The node specified by `node_id` must be a peer, i.e., it must have a direct The node specified by `node_id` must be a peer, i.e., it must have a direct
connection with the node receiving the RPC call, and the connection must be connection with the node receiving the RPC call, and the connection must be

14
doc/lightning-sendonion.7.md
View File

@ -16,7 +16,7 @@ along the route on how to behave. Normally these instructions are indications
on where to forward a payment and what parameters to use, or contain details on where to forward a payment and what parameters to use, or contain details
of the payment for the final hop. However, it is possible to add arbitrary of the payment for the final hop. However, it is possible to add arbitrary
information for hops in the custom onion, allowing for custom extensions that information for hops in the custom onion, allowing for custom extensions that
are not directly supported by c-lightning. are not directly supported by Core Lightning.
The onion is specific to the route that is being used and the *payment_hash* The onion is specific to the route that is being used and the *payment_hash*
used to construct, and therefore cannot be reused for other payments or to used to construct, and therefore cannot be reused for other payments or to
@ -28,10 +28,10 @@ by either of the tools that can generate onions. It contains the payloads
destined for each hop and some metadata. Please refer to [BOLT 04][bolt04] for destined for each hop and some metadata. Please refer to [BOLT 04][bolt04] for
further details. further details.
The *first_hop* parameter instructs c-lightning which peer to send the onion The *first_hop* parameter instructs Core Lightning which peer to send the onion
to. It is a JSON dictionary that corresponds to the first element of the route to. It is a JSON dictionary that corresponds to the first element of the route
array returned by *getroute*. The following is a minimal example telling array returned by *getroute*. The following is a minimal example telling
c-lightning to use any available channel to `022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59` Core Lightning to use any available channel to `022d223620a359a47ff7f7ac447c85c46c923da53389221a0054c11c1e3ca31d59`
to add an HTLC for 1002 millisatoshis and a delay of 21 blocks on top of the current blockheight: to add an HTLC for 1002 millisatoshis and a delay of 21 blocks on top of the current blockheight:
```json ```json
@ -50,13 +50,13 @@ The *label* parameter can be used to provide a human readable reference to
retrieve the payment at a later time. retrieve the payment at a later time.
The *shared_secrets* parameter is a JSON list of 32 byte hex-encoded secrets The *shared_secrets* parameter is a JSON list of 32 byte hex-encoded secrets
that were used when creating the onion. c-lightning can send a payment with a that were used when creating the onion. Core Lightning can send a payment with a
custom onion without the knowledge of these secrets, however it will not be custom onion without the knowledge of these secrets, however it will not be
able to parse an eventual error message since that is encrypted with the able to parse an eventual error message since that is encrypted with the
shared secrets used in the onion. If *shared_secrets* is provided c-lightning shared secrets used in the onion. If *shared_secrets* is provided Core Lightning
will decrypt the error, act accordingly, e.g., add a `channel_update` included will decrypt the error, act accordingly, e.g., add a `channel_update` included
in the error to its network view, and set the details in *listsendpays* in the error to its network view, and set the details in *listsendpays*
correctly. If it is not provided c-lightning will store the encrypted onion, correctly. If it is not provided Core Lightning will store the encrypted onion,
and expose it in *listsendpays* allowing the caller to decrypt it and expose it in *listsendpays* allowing the caller to decrypt it
externally. The following is an example of a 3 hop onion: externally. The following is an example of a 3 hop onion:
@ -68,7 +68,7 @@ externally. The following is an example of a 3 hop onion:
] ]
``` ```
If *shared_secrets* is not provided the c-lightning node does not know how If *shared_secrets* is not provided the Core Lightning node does not know how
long the route is, which channels or nodes are involved, and what an eventual long the route is, which channels or nodes are involved, and what an eventual
error could have been. It can therefore be used for oblivious payments. error could have been. It can therefore be used for oblivious payments.

2
doc/lightning-setchannel.7.md
View File

@ -90,7 +90,7 @@ AUTHOR
Michael Schmoock <<michael@schmoock.net>> is the author of this Michael Schmoock <<michael@schmoock.net>> is the author of this
feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly
responsible for the c-lightning project. responsible for the Core Lightning project.
SEE ALSO SEE ALSO
-------- --------

2
doc/lightning-setchannelfee.7.md
View File

@ -70,7 +70,7 @@ AUTHOR
Michael Schmoock <<michael@schmoock.net>> is the author of this Michael Schmoock <<michael@schmoock.net>> is the author of this
feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly
responsible for the c-lightning project. responsible for the Core Lightning project.
SEE ALSO SEE ALSO
-------- --------

6
doc/lightning-stop.7.md
View File

@ -1,5 +1,5 @@
lightning-stop -- Command to shutdown the c-lightning node. lightning-stop -- Command to shutdown the Core Lightning node.
============================================================ ============================================================--
SYNOPSIS SYNOPSIS
-------- --------
@ -9,7 +9,7 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
The **stop** is a RPC command to shut off the c-lightning node. The **stop** is a RPC command to shut off the Core Lightning node.
EXAMPLE JSON REQUEST EXAMPLE JSON REQUEST
------------ ------------

2
doc/lightning-txprepare.7.md
View File

@ -10,7 +10,7 @@ DESCRIPTION
----------- -----------
The **txprepare** RPC command creates an unsigned transaction which The **txprepare** RPC command creates an unsigned transaction which
spends funds from c-lightning's internal wallet to the outputs specified spends funds from Core Lightning's internal wallet to the outputs specified
in *outputs*. in *outputs*.
The *outputs* is the array of output that include *destination* The *outputs* is the array of output that include *destination*

2
doc/lightning-withdraw.7.md
View File

@ -9,7 +9,7 @@ SYNOPSIS
DESCRIPTION DESCRIPTION
----------- -----------
The **withdraw** RPC command sends funds from c-lightning's internal The **withdraw** RPC command sends funds from Core Lightning's internal
wallet to the address specified in *destination*. wallet to the address specified in *destination*.
The address can be of any Bitcoin accepted type, including bech32. The address can be of any Bitcoin accepted type, including bech32.

10
doc/lightningd-config.5.md
View File

@ -367,7 +367,7 @@ right thing: for the mainnet (bitcoin) network it will try to bind to
port 9735 on IPv4 and IPv6, and will announce it to peers if it seems port 9735 on IPv4 and IPv6, and will announce it to peers if it seems
like a public address. like a public address.
c-lightning also support IPv4/6 address discovery behind NAT routers. Core Lightning also support IPv4/6 address discovery behind NAT routers.
If your node detects an new public address, it will update its announcement. If your node detects an new public address, it will update its announcement.
For this to work you need to forward the TCP port 9735 to your node. For this to work you need to forward the TCP port 9735 to your node.
@ -478,7 +478,7 @@ plugins along with any immediate subdirectories). You can specify
additional paths too: additional paths too:
**plugin**=*PATH* **plugin**=*PATH*
Specify a plugin to run as part of c-lightning. This can be specified Specify a plugin to run as part of Core Lightning. This can be specified
multiple times to add multiple plugins. Note that unless plugins themselves multiple times to add multiple plugins. Note that unless plugins themselves
specify ordering requirements for being called on various hooks, plugins will specify ordering requirements for being called on various hooks, plugins will
be ordered by commandline, then config file. be ordered by commandline, then config file.
@ -505,13 +505,13 @@ disabling a single plugin inside a directory. You can still explicitly
load plugins which have been disabled, using lightning-plugin(7) `start`. load plugins which have been disabled, using lightning-plugin(7) `start`.
**important-plugin**=*PLUGIN* **important-plugin**=*PLUGIN*
Speciy a plugin to run as part of C-lightning. Speciy a plugin to run as part of Core Lightning.
This can be specified multiple times to add multiple plugins. This can be specified multiple times to add multiple plugins.
Plugins specified via this option are considered so important, that if the Plugins specified via this option are considered so important, that if the
plugin stops for any reason (including via lightning-plugin(7) `stop`), plugin stops for any reason (including via lightning-plugin(7) `stop`),
C-lightning will also stop running. Core Lightning will also stop running.
This way, you can monitor crashes of important plugins by simply monitoring This way, you can monitor crashes of important plugins by simply monitoring
if C-lightning terminates. if Core Lightning terminates.
Built-in plugins, which are installed with lightningd(8), are automatically Built-in plugins, which are installed with lightningd(8), are automatically
considered important. considered important.

2
hsmd/hsmd.c
View File

@ -309,7 +309,7 @@ static void create_hsm(int fd)
} }
} }
/*~ We store our root secret in a "hsm_secret" file (like all of c-lightning, /*~ We store our root secret in a "hsm_secret" file (like all of Core Lightning,
* we run in the user's .lightning directory). */ * we run in the user's .lightning directory). */
static void maybe_create_new_hsm(const struct secret *encryption_key, static void maybe_create_new_hsm(const struct secret *encryption_key,
bool random_hsm) bool random_hsm)

2
lightningd/jsonrpc.c
View File

@ -886,7 +886,7 @@ parse_request(struct json_connection *jcon, const jsmntok_t tok[])
return NULL; return NULL;
} }
// Adding a deprecated phase to make sure that all the c-lightning wrapper // Adding a deprecated phase to make sure that all the Core Lightning wrapper
// can migrate all the frameworks // can migrate all the frameworks
if (!deprecated_apis) { if (!deprecated_apis) {
const jsmntok_t *jsonrpc = json_get_member(jcon->buffer, tok, "jsonrpc"); const jsmntok_t *jsonrpc = json_get_member(jcon->buffer, tok, "jsonrpc");

4
lightningd/lightningd.c
View File

@ -1,6 +1,6 @@
/*~ Welcome, wonderful reader! /*~ Welcome, wonderful reader!
* *
* This is the core of c-lightning: the main file of the master daemon * This is the Core of um, Core Lightning: the main file of the master daemon
* `lightningd`. It's mainly cluttered with the miscellany of setup, * `lightningd`. It's mainly cluttered with the miscellany of setup,
* and a few startup sanity checks. * and a few startup sanity checks.
* *
@ -247,7 +247,7 @@ static struct lightningd *new_lightningd(const tal_t *ctx)
/*~ We run a number of plugins (subprocesses that we talk JSON-RPC with) /*~ We run a number of plugins (subprocesses that we talk JSON-RPC with)
* alongside this process. This allows us to have an easy way for users * alongside this process. This allows us to have an easy way for users
* to add their own tools without having to modify the c-lightning source * to add their own tools without having to modify the Core Lightning source
* code. Here we initialize the context that will keep track and control * code. Here we initialize the context that will keep track and control
* the plugins. * the plugins.
*/ */

2
lightningd/plugin_control.c
View File

@ -304,7 +304,7 @@ static const struct json_command plugin_control_command = {
"Control plugins (start, stop, startdir, rescan, list)", "Control plugins (start, stop, startdir, rescan, list)",
.verbose = "Usage :\n" .verbose = "Usage :\n"
"plugin start /path/to/a/plugin\n" "plugin start /path/to/a/plugin\n"
" adds a new plugin to c-lightning\n" " adds a new plugin to Core Lightning\n"
"plugin stop plugin_name\n" "plugin stop plugin_name\n"
" stops an already registered plugin\n" " stops an already registered plugin\n"
"plugin startdir /path/to/a/plugin_dir/\n" "plugin startdir /path/to/a/plugin_dir/\n"

2
plugins/examples/cln-plugin-startup.rs
View File

@ -1,5 +1,5 @@
//! This is a test plugin used to verify that we can compile and run //! This is a test plugin used to verify that we can compile and run
//! plugins using the Rust API against c-lightning. //! plugins using the Rust API against Core Lightning.
#[macro_use] #[macro_use]
extern crate serde_json; extern crate serde_json;
use cln_plugin::{options, Builder, Error, Plugin}; use cln_plugin::{options, Builder, Error, Plugin};

2
plugins/spender/openchannel.c
View File

@ -46,7 +46,7 @@ find_dest_by_channel_id(struct channel_id *cid)
* the PSBT input/outputs in such a way that we can Do The * the PSBT input/outputs in such a way that we can Do The
* Right Thing for each of our peers. * Right Thing for each of our peers.
* *
* c-lightning will make sure that our peer isn't removing/adding * Core Lightning will make sure that our peer isn't removing/adding
* any updates that it's not allowed to (i.e. ours or a different * any updates that it's not allowed to (i.e. ours or a different
* node's that we're pretending are 'ours'). * node's that we're pretending are 'ours').
* *

6
plugins/src/lib.rs
View File

@ -141,7 +141,7 @@ where
/// Build and start the plugin loop. This performs the handshake /// Build and start the plugin loop. This performs the handshake
/// and spawns a new task that accepts incoming messages from /// and spawns a new task that accepts incoming messages from
/// c-lightning and dispatches them to the handlers. It only /// Core Lightning and dispatches them to the handlers. It only
/// returns after completing the handshake to ensure that the /// returns after completing the handshake to ensure that the
/// configuration and initialization was successfull. /// configuration and initialization was successfull.
pub async fn start(mut self) -> Result<Plugin<S>, anyhow::Error> { pub async fn start(mut self) -> Result<Plugin<S>, anyhow::Error> {
@ -159,7 +159,7 @@ where
))); )));
// Now configure the logging, so any `log` call is wrapped // Now configure the logging, so any `log` call is wrapped
// in a JSON-RPC notification and sent to c-lightning // in a JSON-RPC notification and sent to Core Lightning
crate::logging::init(output.clone()).await?; crate::logging::init(output.clone()).await?;
trace!("Plugin logging initialized"); trace!("Plugin logging initialized");
@ -267,7 +267,7 @@ where
(OValue::Integer(_), JValue::Number(n)) => OValue::Integer(n.as_i64().unwrap()), (OValue::Integer(_), JValue::Number(n)) => OValue::Integer(n.as_i64().unwrap()),
(OValue::Boolean(_), JValue::Bool(n)) => OValue::Boolean(*n), (OValue::Boolean(_), JValue::Bool(n)) => OValue::Boolean(*n),
// It's ok to panic, if we get here c-lightning // It's ok to panic, if we get here Core Lightning
// has not enforced the option type. // has not enforced the option type.
(_, _) => panic!("Mismatching types in options: {:?} != {:?}", opt, val), (_, _) => panic!("Mismatching types in options: {:?} != {:?}", opt, val),
}); });

4
poetry.lock generated
View File

@ -512,7 +512,7 @@ python-versions = ">=3.7,<4.0"
[[package]] [[package]]
name = "pyln-client" name = "pyln-client"
version = "0.10.2.post1" version = "0.10.2.post1"
description = "Client library and plugin library for c-lightning" description = "Client library and plugin library for Core Lightning"
category = "main" category = "main"
optional = false optional = false
python-versions = "^3.7" python-versions = "^3.7"
@ -549,7 +549,7 @@ url = "contrib/pyln-proto"
[[package]] [[package]]
name = "pyln-testing" name = "pyln-testing"
version = "0.10.2" version = "0.10.2"
description = "Test your c-lightning integration, plugins or whatever you want" description = "Test your Core Lightning integration, plugins or whatever you want"
category = "dev" category = "dev"
optional = false optional = false
python-versions = "^3.7" python-versions = "^3.7"

2
wire/tlvstream.h
View File

@ -16,7 +16,7 @@ struct tlv_record_type {
/* A single TLV field, consisting of the data and its associated metadata. */ /* A single TLV field, consisting of the data and its associated metadata. */
struct tlv_field { struct tlv_field {
/* If this is a type that is known to c-lightning we have a pointer to /* If this is a type that is known to Core Lightning we have a pointer to
* the metadata. */ * the metadata. */
const struct tlv_record_type *meta; const struct tlv_record_type *meta;