mirror of
https://github.com/ElementsProject/lightning.git
synced 2024-11-19 01:43:36 +01:00
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 <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
parent
8c2f3ab5fe
commit
836c1b805b
2
.github/workflows/ci.yaml
vendored
2
.github/workflows/ci.yaml
vendored
@ -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
|
||||
|
||||
@ -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 ."
|
||||
|
||||
1
Makefile
1
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.
|
||||
|
||||
16
README.md
16
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
|
||||
|
||||
@ -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'
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
# `cln-rpc`: Talk to c-lightning
|
||||
# `cln-rpc`: Talk to Core Lightning
|
||||
|
||||
|
||||
|
||||
2
configure
vendored
2
configure
vendored
@ -1,5 +1,5 @@
|
||||
#! /bin/sh
|
||||
# Simple configure script for c-lightning.
|
||||
# Simple configure script for Core Lightning.
|
||||
|
||||
set -e
|
||||
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -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 ."
|
||||
|
||||
@ -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")
|
||||
|
||||
|
||||
@ -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")
|
||||
|
||||
|
||||
@ -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 <decker.christian@gmail.com>"]
|
||||
license = "BSD-MIT"
|
||||
readme = "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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
"""
|
||||
|
||||
@ -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 <decker.christian@gmail.com>"]
|
||||
license = "BSD-MIT"
|
||||
readme = "README.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.
|
||||
|
||||
@ -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:
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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!
|
||||
|
||||
|
||||
@ -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
|
||||
open-source projects by allowing maintainers to verify and certify that a
|
||||
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
|
||||
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.
|
||||
|
||||
The steps involved in creating reproducible builds are:
|
||||
@ -109,7 +109,7 @@ DISTRIB_DESCRIPTION="Ubuntu 18.04 LTS"
|
||||
## Builder image setup
|
||||
|
||||
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.
|
||||
|
||||
For this purpose we have a number of Dockerfiles in the
|
||||
|
||||
@ -218,7 +218,7 @@ cautiously as too many parameters get unwieldy quickly.
|
||||
## Github Workflows
|
||||
|
||||
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
|
||||
|
||||
|
||||
72
doc/TOR.md
72
doc/TOR.md
@ -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`
|
||||
|
||||
@ -19,13 +19,13 @@ just check that this line is present in the Tor config file `/etc/tor/torrc`:
|
||||
|
||||
`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.
|
||||
Only enable this if you are sure about the implications.
|
||||
|
||||
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.
|
||||
|
||||
@ -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
|
||||
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.
|
||||
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
|
||||
@ -113,12 +113,12 @@ the user that will run `lightningd` and check this command:
|
||||
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.
|
||||
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
|
||||
command line):
|
||||
|
||||
@ -129,25 +129,25 @@ addr=statictor:127.0.0.1:9051
|
||||
always-use-proxy=true
|
||||
```
|
||||
|
||||
1. `proxy` informs C-Lightning that you have a SOCKS5 proxy at port 9050.
|
||||
C-Lightning will assume that this is a Tor proxy, port 9050 is the
|
||||
1. `proxy` informs Core Lightning that you have a SOCKS5 proxy at port 9050.
|
||||
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`
|
||||
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.
|
||||
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
|
||||
or keep the old one, but don't keep both.
|
||||
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.
|
||||
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
|
||||
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
|
||||
address to them explicitly (i.e. autopilots and the like will likely
|
||||
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.
|
||||
You can set this to `false` or remove it,
|
||||
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).
|
||||
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
|
||||
@ -171,30 +171,30 @@ addr=statictor:127.0.0.1:9151
|
||||
always-use-proxy=true
|
||||
```
|
||||
|
||||
You will have to run C-Lightning after launching Tor Browser or Orbot,
|
||||
and keep Tor Browser or Orbot open as long as C-Lightning is running,
|
||||
You will have to run Core Lightning after launching Tor Browser or Orbot,
|
||||
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
|
||||
to you, anywhere (no port forwarding! works wherever Tor works!), and
|
||||
you do not have to do anything more complicated than download and
|
||||
install Tor Browser.
|
||||
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.
|
||||
|
||||
### 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
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
@ -218,14 +218,14 @@ You will find the newly created address (myaddress.onion) with:
|
||||
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
|
||||
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 accept control commands from c-lightning, either by using a cookie,
|
||||
To have Core Lightning control your Tor addresses, you have to tell Tor
|
||||
to accept control commands from Core Lightning, either by using a cookie,
|
||||
or a password.
|
||||
|
||||
##### 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
|
||||
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
|
||||
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
|
||||
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
|
||||
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).
|
||||
|
||||
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 |
|
||||
| 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] |
|
||||
| 5 | Not Announced | FIXED BY C-LIGHTNING | Incoming [1] |
|
||||
| 5 | Not Announced | FIXED BY CORE LIGHTNING | Incoming [1] |
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
Tor-assigned onion address).
|
||||
|
||||
@ -380,12 +380,12 @@ addr=yourIPAddress: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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
Tor-assigned onion address).
|
||||
|
||||
@ -416,11 +416,11 @@ proxy=127.0.0.1:9050
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
```
|
||||
|
||||
@ -59,7 +59,7 @@ master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = 'c-lightning'
|
||||
author = 'c-lightning Developers'
|
||||
author = 'Core Lightning Developers'
|
||||
copyright = datetime.now().strftime('2015 — %Y, {}'.format(author))
|
||||
|
||||
# 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.
|
||||
# "<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.
|
||||
#
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
c-lightning Documentation
|
||||
=========================
|
||||
Core Lightning Documentation
|
||||
============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
@ -26,7 +26,7 @@ indefinitely until the peer is online and can negotiate a mutual close.
|
||||
The default is 2 days (172800 seconds).
|
||||
|
||||
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
|
||||
taproot addresses (or other v1+ segwit) are not allowed. Tell your
|
||||
friends to upgrade!
|
||||
|
||||
@ -11,7 +11,7 @@ DESCRIPTION
|
||||
|
||||
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
|
||||
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
|
||||
payload destined for that node. The following is an example of a 3 hop onion:
|
||||
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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
|
||||
one-element array), to form a hierarchy. Using the first element of
|
||||
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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*
|
||||
is specified and the generation of the data does not exactly match.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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:
|
||||
a *key* with children won't have a *hex* or *generation* entry.
|
||||
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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.
|
||||
*status* can be either *offered* or *settled* or *failed* or *local_failed*
|
||||
|
||||
@ -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
|
||||
|
||||
@ -15,7 +15,7 @@ that is shared by all channels.
|
||||
|
||||
If not already connected, **multifundchannel** will automatically attempt
|
||||
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).
|
||||
|
||||
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.
|
||||
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,
|
||||
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.
|
||||
If you immediately **multifundchannel** with that peer, it could
|
||||
trigger this connect-forget-disconnect behavior, causing the
|
||||
|
||||
@ -9,7 +9,7 @@ SYNOPSIS
|
||||
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*,
|
||||
which is an array containing objects of the form `{address: amount}`.
|
||||
The `amount` may be the string *"all"*, indicating that all onchain funds
|
||||
|
||||
@ -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
|
||||
--------
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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.
|
||||
|
||||
|
||||
@ -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
|
||||
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
|
||||
c-lightning.
|
||||
Core Lightning.
|
||||
|
||||
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
|
||||
|
||||
@ -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
|
||||
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
|
||||
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*
|
||||
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
|
||||
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
|
||||
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:
|
||||
|
||||
```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.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
error could have been. It can therefore be used for oblivious payments.
|
||||
|
||||
|
||||
@ -90,7 +90,7 @@ AUTHOR
|
||||
|
||||
Michael Schmoock <<michael@schmoock.net>> is the author of this
|
||||
feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly
|
||||
responsible for the c-lightning project.
|
||||
responsible for the Core Lightning project.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
@ -70,7 +70,7 @@ AUTHOR
|
||||
|
||||
Michael Schmoock <<michael@schmoock.net>> is the author of this
|
||||
feature. Rusty Russell <<rusty@rustcorp.com.au>> is mainly
|
||||
responsible for the c-lightning project.
|
||||
responsible for the Core Lightning project.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
lightning-stop -- Command to shutdown the c-lightning node.
|
||||
============================================================
|
||||
lightning-stop -- Command to shutdown the Core Lightning node.
|
||||
============================================================--
|
||||
|
||||
SYNOPSIS
|
||||
--------
|
||||
@ -9,7 +9,7 @@ SYNOPSIS
|
||||
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
|
||||
------------
|
||||
|
||||
@ -10,7 +10,7 @@ DESCRIPTION
|
||||
-----------
|
||||
|
||||
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*.
|
||||
|
||||
The *outputs* is the array of output that include *destination*
|
||||
|
||||
@ -9,7 +9,7 @@ SYNOPSIS
|
||||
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*.
|
||||
|
||||
The address can be of any Bitcoin accepted type, including bech32.
|
||||
|
||||
@ -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
|
||||
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.
|
||||
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:
|
||||
|
||||
**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
|
||||
specify ordering requirements for being called on various hooks, plugins will
|
||||
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`.
|
||||
|
||||
**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.
|
||||
Plugins specified via this option are considered so important, that if the
|
||||
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
|
||||
if C-lightning terminates.
|
||||
if Core Lightning terminates.
|
||||
Built-in plugins, which are installed with lightningd(8), are automatically
|
||||
considered important.
|
||||
|
||||
|
||||
@ -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). */
|
||||
static void maybe_create_new_hsm(const struct secret *encryption_key,
|
||||
bool random_hsm)
|
||||
|
||||
@ -886,7 +886,7 @@ parse_request(struct json_connection *jcon, const jsmntok_t tok[])
|
||||
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
|
||||
if (!deprecated_apis) {
|
||||
const jsmntok_t *jsonrpc = json_get_member(jcon->buffer, tok, "jsonrpc");
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
/*~ 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,
|
||||
* 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)
|
||||
* 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
|
||||
* the plugins.
|
||||
*/
|
||||
|
||||
@ -304,7 +304,7 @@ static const struct json_command plugin_control_command = {
|
||||
"Control plugins (start, stop, startdir, rescan, list)",
|
||||
.verbose = "Usage :\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"
|
||||
" stops an already registered plugin\n"
|
||||
"plugin startdir /path/to/a/plugin_dir/\n"
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
//! 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]
|
||||
extern crate serde_json;
|
||||
use cln_plugin::{options, Builder, Error, Plugin};
|
||||
|
||||
@ -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
|
||||
* 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
|
||||
* node's that we're pretending are 'ours').
|
||||
*
|
||||
|
||||
@ -141,7 +141,7 @@ where
|
||||
|
||||
/// Build and start the plugin loop. This performs the handshake
|
||||
/// 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
|
||||
/// configuration and initialization was successfull.
|
||||
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
|
||||
// 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?;
|
||||
trace!("Plugin logging initialized");
|
||||
|
||||
@ -267,7 +267,7 @@ where
|
||||
(OValue::Integer(_), JValue::Number(n)) => OValue::Integer(n.as_i64().unwrap()),
|
||||
(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.
|
||||
(_, _) => panic!("Mismatching types in options: {:?} != {:?}", opt, val),
|
||||
});
|
||||
|
||||
4
poetry.lock
generated
4
poetry.lock
generated
@ -512,7 +512,7 @@ python-versions = ">=3.7,<4.0"
|
||||
[[package]]
|
||||
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"
|
||||
category = "main"
|
||||
optional = false
|
||||
python-versions = "^3.7"
|
||||
@ -549,7 +549,7 @@ url = "contrib/pyln-proto"
|
||||
[[package]]
|
||||
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"
|
||||
category = "dev"
|
||||
optional = false
|
||||
python-versions = "^3.7"
|
||||
|
||||
@ -16,7 +16,7 @@ struct tlv_record_type {
|
||||
|
||||
/* A single TLV field, consisting of the data and its associated metadata. */
|
||||
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. */
|
||||
const struct tlv_record_type *meta;
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user