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

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 <[email protected]>

.github/workflows/ci.yaml

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

Dockerfile

@@ -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:
-# * downloader: Download litecoin/bitcoin and qemu binaries needed for c-lightning
-# * builder: Compile c-lightning dependencies, then c-lightning itself with static linking
+# * downloader: Download litecoin/bitcoin and qemu binaries needed for core-lightning
+# * builder: Compile core-lightning dependencies, then c-lightning itself with static linking
 # * final: Copy the binaries required at 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 ."

Makefile

@@ -17,6 +17,7 @@ SUPPRESS_OUTPUT :=
 endif
 
 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
 
 # We use our own internal ccan copy.

README.md

@@ -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)
     * [Installation](#installation)
@@ -32,7 +32,7 @@ Don't hesitate to reach out to us on IRC at [#lightning-dev @ libera.chat][irc1]
 
 ## 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.
 
 ### Installation
@@ -95,7 +95,7 @@ This creates a `.lightning/` subdirectory in your home directory: see `man -l do
 
 ### 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>`
 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
 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:
 
 	https://github.com/lightningd/plugins
@@ -206,11 +206,11 @@ To use a configuration file, create a file named `config` within your top-level
 
 ### 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.
 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.
-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`.
+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 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.
 
 ### HD wallet encryption

action.yml

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

bitcoin/psbt.h

@@ -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);
 
-/* psbt_make_key - Create a new, proprietary c-lightning key
+/* psbt_make_key - Create a new, proprietary Core Lightning key
  *
  * @ctx - allocation context
  * @key_subtype - type for this key

channeld/full_channel.c

@@ -462,7 +462,7 @@ static bool htlc_dust(const struct channel *channel,
  * leads to the channel starving at the feast!  This was reported by
  * ACINQ's @t-bast
  * (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).
  *
  * To mostly avoid this situation, at least from our side, we apply an

cln-rpc/README.md

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

configure

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

connectd/multiplex.c

@@ -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",
 				    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! */
 	for (i = 0; i < tal_count(ignored); i++) {
 		if (ignored[i] < ' ' || ignored[i] == 127)

contrib/docker/linuxarm64v8.Dockerfile

@@ -1,7 +1,7 @@
 # This dockerfile is meant to cross compile with a x64 machine for a arm64v8 host
 # It is using multi stage build: 
-# * downloader: Download litecoin/bitcoin and qemu binaries needed for c-lightning
-# * builder: Cross compile c-lightning dependencies, then c-lightning itself with static linking
+# * downloader: Download litecoin/bitcoin and qemu binaries needed for Core Lightning
+# * builder: Cross compile Core Lightning dependencies, then Core Lightning itself with static linking
 # * final: Copy the binaries required at 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 ."

contrib/pylightning/README.md

@@ -18,7 +18,7 @@ pip install pylightning
 ```
 
 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:
 
 ```bash
@@ -43,7 +43,7 @@ Generate invoice on one daemon and pay it on the other
 from lightning import LightningRpc
 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")
 l5 = LightningRpc("/tmp/lightning5/lightning-rpc")
 

contrib/pyln-client/README.md

@@ -15,7 +15,7 @@ pip install pyln-client
 ```
 
 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:
 
 ```bash
@@ -40,7 +40,7 @@ Generate invoice on one daemon and pay it on the other
 from pyln.client import LightningRpc
 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")
 l5 = LightningRpc("/tmp/lightning5/lightning-rpc")
 

contrib/pyln-client/pyproject.toml

@@ -1,7 +1,7 @@
 [tool.poetry]
 name = "pyln-client"
 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 <[email protected]>"]
 license = "BSD-MIT"
 readme = "README.md"

contrib/pyln-proto/README.md

@@ -15,7 +15,7 @@ pip install pyln-proto
 ```
 
 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:
 
 ```bash

contrib/pyln-proto/tests/test_onion.py

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

contrib/pyln-testing/README.md

@@ -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
-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
 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.
 
 ## Installation
@@ -17,7 +17,7 @@ pip install pyln-testing
 ```
 
 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:
 
 ```bash

contrib/pyln-testing/pyln/testing/utils.py

@@ -53,7 +53,7 @@ def env(name, default=None):
     """Access to environment variables
 
     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.
 
     """

contrib/pyln-testing/pyproject.toml

@@ -1,7 +1,7 @@
 [tool.poetry]
 name = "pyln-testing"
 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 <[email protected]>"]
 license = "BSD-MIT"
 readme = "README.md"

doc/FAQ.md

@@ -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.
 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.
 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
 the default `bitcoind` max.
 
-### Can I use C-lightning on mobile ?
+### Can I use Core Lightning on mobile ?
 
 #### 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
 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).
 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:
 - `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.
 - `--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.

doc/HACKING.md

@@ -91,7 +91,7 @@ Here's a list of parts, with notes:
 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.
 You can log console messages with log_info() in lightningd and status_debug()
 in other subdaemons.
@@ -110,7 +110,7 @@ subdaemon will be stopped (it sends itself a SIGSTOP); you'll need to
 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
 under `~/.lightning/<network>/`.
 You can run queries against this file like so:

doc/INSTALL.md

@@ -138,7 +138,7 @@ To Build on FreeBSD
 
 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):
 
     # pkg install c-lightning
@@ -285,7 +285,7 @@ To cross-compile for Android
 
 Make a standalone toolchain as per
 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
 such as:
@@ -370,7 +370,7 @@ Download and build gmp:
     make
     make install
 
-Then, build c-lightning with the following commands:
+Then, build Core Lightning with the following commands:
 
     ./configure
     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.
 
-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).
 
 To compile for Alpine

doc/PLUGINS.md

@@ -1,7 +1,7 @@
 # Plugins
 
 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
 variety of ways:
 
@@ -873,7 +873,7 @@ rely on the shutdown notification always been send.
 ## Hooks
 
 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
 events in the daemon. A hook can then decide how `lightningd` should
 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
 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
-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:
 
@@ -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
 `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
-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
 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
 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
 `{'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
 
-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
 different operations, or write your own for your favourite Bitcoin data source!