docs: unify code and shell cmd blocks
This commit is contained in:
Oliver Gugger
parent
b20afc0679
commit
2c634bfaf3
@ -12,8 +12,8 @@ There are two flavors of Dockerfiles available:
|
||||
To build a standalone development image from the local source directory, use the
|
||||
following command:
|
||||
|
||||
```
|
||||
$ docker build --tag=myrepository/lnd-dev -f dev.Dockerfile .
|
||||
```shell
|
||||
⛰ docker build --tag=myrepository/lnd-dev -f dev.Dockerfile .
|
||||
```
|
||||
|
||||
There is also a `docker-compose` setup available for development or testing that
|
||||
@ -28,16 +28,16 @@ Docker container, adding the appropriate command-line options as parameters.
|
||||
|
||||
You first need to build the `lnd` docker image:
|
||||
|
||||
```
|
||||
$ docker build --tag=myrepository/lnd --build-arg checkout=v0.11.1-beta .
|
||||
```shell
|
||||
⛰ docker build --tag=myrepository/lnd --build-arg checkout=v0.11.1-beta .
|
||||
```
|
||||
|
||||
It is recommended that you checkout the latest released tag.
|
||||
|
||||
You can continue by creating and running the container:
|
||||
|
||||
```
|
||||
$ docker run myrepository/lnd [command-line options]
|
||||
```shell
|
||||
⛰ docker run myrepository/lnd [command-line options]
|
||||
```
|
||||
|
||||
## Production (official images)
|
||||
@ -49,8 +49,8 @@ images of `lnd` available in the
|
||||
You can just pull those images by specifying a release tag:
|
||||
|
||||
```shell
|
||||
$ docker pull lightninglabs/lnd:v0.12.0-beta
|
||||
$ docker run lightninglabs/lnd [command-line options]
|
||||
⛰ docker pull lightninglabs/lnd:v0.12.0-beta
|
||||
⛰ docker run lightninglabs/lnd [command-line options]
|
||||
```
|
||||
|
||||
### Verifying docker images
|
||||
@ -61,11 +61,11 @@ script in the image that can be called (before starting the container for
|
||||
example):
|
||||
|
||||
```shell
|
||||
$ docker pull lightninglabs/lnd:v0.12.0-beta
|
||||
$ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta /verify-install.sh
|
||||
$ OK=$?
|
||||
$ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
|
||||
$ docker run lightninglabs/lnd [command-line options]
|
||||
⛰ docker pull lightninglabs/lnd:v0.12.0-beta
|
||||
⛰ docker run --rm --entrypoint="" lightninglabs/lnd:v0.12.0-beta /verify-install.sh
|
||||
⛰ OK=$?
|
||||
⛰ if [ "$OK" -ne "0" ]; then echo "Verification failed!"; exit 1; done
|
||||
⛰ docker run lightninglabs/lnd [command-line options]
|
||||
```
|
||||
|
||||
## Volumes
|
||||
@ -75,28 +75,28 @@ persist through container restarts.
|
||||
|
||||
You can also optionally manually specify a local folder to be used as a volume:
|
||||
|
||||
```
|
||||
$ docker create --name=mylndcontainer -v /media/lnd-docker/:/root/.lnd myrepository/lnd [command-line options]
|
||||
```shell
|
||||
⛰ docker create --name=mylndcontainer -v /media/lnd-docker/:/root/.lnd myrepository/lnd [command-line options]
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
Here is an example testnet `lnd` that uses Neutrino:
|
||||
|
||||
```
|
||||
$ docker run --name lnd-testnet myrepository/lnd --bitcoin.active --bitcoin.testnet --bitcoin.node=neutrino --neutrino.connect=faucet.lightning.community
|
||||
```shell
|
||||
⛰ docker run --name lnd-testnet myrepository/lnd --bitcoin.active --bitcoin.testnet --bitcoin.node=neutrino --neutrino.connect=faucet.lightning.community
|
||||
```
|
||||
|
||||
Create a wallet (and write down the seed):
|
||||
|
||||
```
|
||||
$ docker exec -it lnd-testnet lncli create
|
||||
```shell
|
||||
⛰ docker exec -it lnd-testnet lncli create
|
||||
```
|
||||
|
||||
Confirm `lnd` has begun to synchronize:
|
||||
|
||||
```
|
||||
$ docker logs lnd-testnet
|
||||
```shell
|
||||
⛰ docker logs lnd-testnet
|
||||
[snipped]
|
||||
2018-05-01 02:28:01.201 [INF] RPCS: RPC server listening on 127.0.0.1:10009
|
||||
2018-05-01 02:28:01.201 [INF] LTND: Waiting for chain backend to finish sync, start_height=2546
|
||||
@ -113,24 +113,24 @@ to expose RPC ports, use `btcd` or `bitcoind`, or add additional chains.
|
||||
To test the Docker production image locally, run the following from
|
||||
the project root:
|
||||
|
||||
```
|
||||
$ docker build . -t myrepository/lnd:master
|
||||
```shell
|
||||
⛰ docker build . -t myrepository/lnd:master
|
||||
```
|
||||
|
||||
To choose a specific branch or tag instead, use the "checkout" build-arg. For example, to build the latest commits in master:
|
||||
|
||||
```
|
||||
$ docker build . --build-arg checkout=v0.8.0-beta -t myrepository/lnd:v0.8.0-beta
|
||||
```shell
|
||||
⛰ docker build . --build-arg checkout=v0.8.0-beta -t myrepository/lnd:v0.8.0-beta
|
||||
```
|
||||
|
||||
To build the image using the most current tag:
|
||||
|
||||
```
|
||||
$ docker build . --build-arg checkout=$(git describe --tags `git rev-list --tags --max-count=1`) -t myrepository/lnd:latest-tag
|
||||
```shell
|
||||
⛰ docker build . --build-arg checkout=$(git describe --tags `git rev-list --tags --max-count=1`) -t myrepository/lnd:latest-tag
|
||||
```
|
||||
|
||||
Once the image has been built and tagged locally, start the container:
|
||||
|
||||
```
|
||||
docker run --name=lnd-testnet -it myrepository/lnd:latest-tag --bitcoin.active --bitcoin.testnet --bitcoin.node=neutrino --neutrino.connect=faucet.lightning.community
|
||||
```shell
|
||||
⛰ docker run --name=lnd-testnet -it myrepository/lnd:latest-tag --bitcoin.active --bitcoin.testnet --bitcoin.node=neutrino --neutrino.connect=faucet.lightning.community
|
||||
```
|
||||
|
||||
@ -67,10 +67,10 @@ To build a specific git tag of `lnd`, simply run the following steps (assuming
|
||||
`v0.x.y-beta` is the tagged version to build):
|
||||
|
||||
```shell
|
||||
git clone https://github.com/lightningnetwork/lnd
|
||||
cd lnd
|
||||
git checkout v0.x.y-beta
|
||||
make docker-release tag=v0.x.y-beta
|
||||
⛰ git clone https://github.com/lightningnetwork/lnd
|
||||
⛰ cd lnd
|
||||
⛰ git checkout v0.x.y-beta
|
||||
⛰ make docker-release tag=v0.x.y-beta
|
||||
```
|
||||
|
||||
This will create a directory called `lnd-v0.x.y-beta` that contains the release
|
||||
@ -150,9 +150,9 @@ version if there are database migrations present.
|
||||
`~/go`. You will also need to add `$GOPATH/bin` to your `PATH`. This ensures
|
||||
that your shell will be able to detect the binaries you install.
|
||||
|
||||
```bash
|
||||
export GOPATH=~/gocode
|
||||
export PATH=$PATH:$GOPATH/bin
|
||||
```shell
|
||||
⛰ export GOPATH=~/gocode
|
||||
⛰ export PATH=$PATH:$GOPATH/bin
|
||||
```
|
||||
|
||||
We recommend placing the above in your .bashrc or in a setup script so that
|
||||
@ -169,10 +169,10 @@ version if there are database migrations present.
|
||||
|
||||
With the preliminary steps completed, to install `lnd`, `lncli`, and all
|
||||
related dependencies run the following commands:
|
||||
```
|
||||
git clone https://github.com/lightningnetwork/lnd
|
||||
cd lnd
|
||||
make install
|
||||
```shell
|
||||
⛰ git clone https://github.com/lightningnetwork/lnd
|
||||
⛰ cd lnd
|
||||
⛰ make install
|
||||
```
|
||||
|
||||
The command above will install the current _master_ branch of `lnd`. If you
|
||||
@ -181,11 +181,11 @@ unstable), then [visit then release page to locate the latest
|
||||
release](https://github.com/lightningnetwork/lnd/releases). Assuming the name
|
||||
of the release is `v0.x.x`, then you can compile this release from source with
|
||||
a small modification to the above command:
|
||||
```
|
||||
git clone https://github.com/lightningnetwork/lnd
|
||||
cd lnd
|
||||
git checkout v0.x.x
|
||||
make install
|
||||
```shell
|
||||
⛰ git clone https://github.com/lightningnetwork/lnd
|
||||
⛰ cd lnd
|
||||
⛰ git checkout v0.x.x
|
||||
⛰ make install
|
||||
```
|
||||
|
||||
|
||||
@ -197,35 +197,35 @@ For Windows WSL users, make will need to be referenced directly via
|
||||
/usr/bin/make/, or alternatively by wrapping quotation marks around make,
|
||||
like so:
|
||||
|
||||
```
|
||||
/usr/bin/make && /usr/bin/make install
|
||||
```shell
|
||||
⛰ /usr/bin/make && /usr/bin/make install
|
||||
|
||||
"make" && "make" install
|
||||
⛰ "make" && "make" install
|
||||
```
|
||||
|
||||
On FreeBSD, use gmake instead of make.
|
||||
|
||||
Alternatively, if one doesn't wish to use `make`, then the `go` commands can be
|
||||
used directly:
|
||||
```
|
||||
GO111MODULE=on go install -v ./...
|
||||
```shell
|
||||
⛰ GO111MODULE=on go install -v ./...
|
||||
```
|
||||
|
||||
**Updating**
|
||||
|
||||
To update your version of `lnd` to the latest version run the following
|
||||
commands:
|
||||
```
|
||||
cd $GOPATH/src/github.com/lightningnetwork/lnd
|
||||
git pull
|
||||
make clean && make && make install
|
||||
```shell
|
||||
⛰ cd $GOPATH/src/github.com/lightningnetwork/lnd
|
||||
⛰ git pull
|
||||
⛰ make clean && make && make install
|
||||
```
|
||||
|
||||
On FreeBSD, use gmake instead of make.
|
||||
|
||||
Alternatively, if one doesn't wish to use `make`, then the `go` commands can be
|
||||
used directly:
|
||||
```
|
||||
```shell
|
||||
cd $GOPATH/src/github.com/lightningnetwork/lnd
|
||||
git pull
|
||||
GO111MODULE=on go install -v ./...
|
||||
|
||||
@ -3,10 +3,10 @@ Makefile
|
||||
|
||||
To build, verify, and install `lnd` from source, use the following
|
||||
commands:
|
||||
```
|
||||
make
|
||||
make check
|
||||
make install
|
||||
```shell
|
||||
⛰ make
|
||||
⛰ make check
|
||||
⛰ make install
|
||||
```
|
||||
|
||||
The command `make check` requires `bitcoind` (almost any version should do) to
|
||||
@ -144,7 +144,7 @@ until an error occurs. Useful for hunting flakes.
|
||||
|
||||
Example:
|
||||
```shell
|
||||
$ make flakehunter-parallel icase='(data_loss_protection|channel_backup)' backend=neutrino
|
||||
⛰ make flakehunter-parallel icase='(data_loss_protection|channel_backup)' backend=neutrino
|
||||
```
|
||||
|
||||
`lint`
|
||||
|
||||
@ -226,7 +226,7 @@ func DeriveRevocationPubkey(commitPubKey *btcec.PublicKey,
|
||||
obvious<br /><br />
|
||||
|
||||
**WRONG**
|
||||
```Go
|
||||
```go
|
||||
// return err if amt is less than 546
|
||||
if amt < 546 {
|
||||
return err
|
||||
@ -256,7 +256,7 @@ being provided here.
|
||||
|
||||
Here’s a model Git commit message:
|
||||
|
||||
```
|
||||
```text
|
||||
Short (50 chars or less) summary of changes
|
||||
|
||||
More detailed explanatory text, if necessary. Wrap it to about 72
|
||||
@ -506,13 +506,13 @@ with out testing infrastructure, or simply make a PR into `lnd` that will build
|
||||
without any further work, the `go.mod` and `go.sum` files will need to be
|
||||
updated. Luckily, the `go mod` command has a handy tool to do this
|
||||
automatically so developers don't need to manually edit the `go.mod` file:
|
||||
```
|
||||
go mod edit -replace=IMPORT-PATH-IN-LND@LND-VERSION=DEV-FORK-IMPORT-PATH@DEV-FORK-VERSION
|
||||
```shell
|
||||
⛰ go mod edit -replace=IMPORT-PATH-IN-LND@LND-VERSION=DEV-FORK-IMPORT-PATH@DEV-FORK-VERSION
|
||||
```
|
||||
|
||||
Here's an example replacing the `lightning-onion` version checked into `lnd` with a version in roasbeef's fork:
|
||||
```
|
||||
go mod edit -replace=github.com/lightningnetwork/lightning-onion@v0.0.0-20180605012408-ac4d9da8f1d6=github.com/roasbeef/lightning-onion@2e5ae87696046298365ab43bcd1cf3a7a1d69695
|
||||
```shell
|
||||
⛰ go mod edit -replace=github.com/lightningnetwork/lightning-onion@v0.0.0-20180605012408-ac4d9da8f1d6=github.com/roasbeef/lightning-onion@2e5ae87696046298365ab43bcd1cf3a7a1d69695
|
||||
```
|
||||
|
||||
<a name="LogLevels" />
|
||||
|
||||
@ -37,7 +37,7 @@ First, you'll want to run `tor` locally before starting up `lnd`. Depending on
|
||||
how you installed Tor, you'll find the configuration file at
|
||||
`/usr/local/etc/tor/torrc`. Here's an example configuration file that we'll be
|
||||
using for the remainder of the tutorial:
|
||||
```
|
||||
```text
|
||||
SOCKSPort 9050
|
||||
Log notice stdout
|
||||
ControlPort 9051
|
||||
@ -45,7 +45,7 @@ CookieAuthentication 1
|
||||
```
|
||||
|
||||
With the configuration file created, you'll then want to start the Tor daemon:
|
||||
```
|
||||
```shell
|
||||
⛰ tor
|
||||
Feb 05 17:02:06.501 [notice] Tor 0.3.1.8 (git-ad5027f7dc790624) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2l, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
|
||||
Feb 05 17:02:06.502 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
|
||||
@ -55,7 +55,7 @@ Feb 05 17:02:06.506 [notice] Opening Control listener on 127.0.0.1:9051
|
||||
```
|
||||
|
||||
Once the `tor` daemon has started and it has finished bootstrapping, you'll see this in the logs:
|
||||
```
|
||||
```text
|
||||
Feb 05 17:02:06.000 [notice] Bootstrapped 0%: Starting
|
||||
Feb 05 17:02:07.000 [notice] Starting with guard context "default"
|
||||
Feb 05 17:02:07.000 [notice] Bootstrapped 80%: Connecting to the Tor network
|
||||
@ -68,7 +68,7 @@ Feb 05 17:02:11.000 [notice] Bootstrapped 100%: Done
|
||||
This indicates the daemon is fully bootstrapped and ready to proxy connections.
|
||||
At this point, we can now start `lnd` with the relevant arguments:
|
||||
|
||||
```
|
||||
```shell
|
||||
⛰ ./lnd -h
|
||||
|
||||
<snip>
|
||||
@ -132,7 +132,7 @@ circuit.
|
||||
|
||||
Activating stream isolation is very straightforward, we only require the
|
||||
specification of an additional argument:
|
||||
```
|
||||
```shell
|
||||
⛰ ./lnd --tor.active --tor.streamisolation
|
||||
```
|
||||
|
||||
@ -170,7 +170,7 @@ To prevent unintentional leaking of identifying information, it is also necessar
|
||||
to add the flag `listen=localhost`.
|
||||
|
||||
For example, v3 onion services can be used with the following flags:
|
||||
```
|
||||
```shell
|
||||
⛰ ./lnd --tor.active --tor.v3 --listen=localhost
|
||||
```
|
||||
|
||||
|
||||
@ -15,14 +15,14 @@ data ahead of time.
|
||||
You can enable debug logging in `lnd` by passing the `--debuglevel` flag. For
|
||||
example, to increase the log level from `info` to `debug`:
|
||||
|
||||
```
|
||||
$ lnd --debuglevel=debug
|
||||
```shell
|
||||
⛰ lnd --debuglevel=debug
|
||||
```
|
||||
|
||||
You may also specify logging per-subsystem, like this:
|
||||
|
||||
```
|
||||
$ lnd --debuglevel=<subsystem>=<level>,<subsystem2>=<level>,...
|
||||
```shell
|
||||
⛰ lnd --debuglevel=<subsystem>=<level>,<subsystem2>=<level>,...
|
||||
```
|
||||
|
||||
## Capturing pprof data with `lnd`
|
||||
@ -34,14 +34,14 @@ Go. The profiler has negligible performance overhead during normal operations
|
||||
|
||||
To enable this ability, start `lnd` with the `--profile` option using a free port.
|
||||
|
||||
```
|
||||
$ lnd --profile=9736
|
||||
```shell
|
||||
⛰ lnd --profile=9736
|
||||
```
|
||||
|
||||
Now, with `lnd` running, you can use the pprof endpoint on port 9736 to collect
|
||||
runtime profiling data. You can fetch this data using `curl` like so:
|
||||
|
||||
```
|
||||
$ curl http://localhost:9736/debug/pprof/goroutine?debug=1
|
||||
```shell
|
||||
⛰ curl http://localhost:9736/debug/pprof/goroutine?debug=1
|
||||
...
|
||||
```
|
||||
|
||||
14
docs/etcd.md
14
docs/etcd.md
@ -14,8 +14,8 @@ on bitcoin mainnet.
|
||||
|
||||
To create a dev build of LND with etcd support use the following command:
|
||||
|
||||
```
|
||||
make tags="kvdb_etcd"
|
||||
```shell
|
||||
⛰ make tags="kvdb_etcd"
|
||||
```
|
||||
|
||||
The important tag is the `kvdb_etcd`, without which the binary is built without
|
||||
@ -29,8 +29,8 @@ directory.
|
||||
|
||||
To start your local etcd instance for testing run:
|
||||
|
||||
```
|
||||
./etcd \
|
||||
```shell
|
||||
⛰ ./etcd \
|
||||
--auto-tls \
|
||||
--advertise-client-urls=https://127.0.0.1:2379 \
|
||||
--listen-client-urls=https://0.0.0.0:2379 \
|
||||
@ -51,8 +51,8 @@ through command line flags or in `lnd.conf`.
|
||||
|
||||
Sample command line:
|
||||
|
||||
```
|
||||
./lnd-debug \
|
||||
```shell
|
||||
⛰ ./lnd-debug \
|
||||
--db.backend=etcd \
|
||||
--db.etcd.host=127.0.0.1:2379 \
|
||||
--db.etcd.certfile=/home/user/etcd/bin/default.etcd/fixtures/client/cert.pem \
|
||||
@ -62,7 +62,7 @@ Sample command line:
|
||||
|
||||
Sample `lnd.conf` (with other setting omitted):
|
||||
|
||||
```
|
||||
```text
|
||||
[db]
|
||||
backend=etcd
|
||||
etcd.host=127.0.0.1:2379
|
||||
|
||||
18
docs/fuzz.md
18
docs/fuzz.md
@ -6,24 +6,24 @@ The `fuzz` package is organized into subpackages which are named after the `lnd`
|
||||
This section will cover setup and installation of `go-fuzz` and fuzzing binaries.
|
||||
|
||||
* First, we must get `go-fuzz`.
|
||||
```
|
||||
$ go get -u github.com/dvyukov/go-fuzz/...
|
||||
```shell
|
||||
⛰ go get -u github.com/dvyukov/go-fuzz/...
|
||||
```
|
||||
* The following is a command to build all fuzzing harnesses for a specific package.
|
||||
```
|
||||
$ cd fuzz/<package>
|
||||
$ find * -maxdepth 1 -regex '[A-Za-z0-9\-_.]'* -not -name fuzz_utils.go | sed 's/\.go$//1' | xargs -I % sh -c 'go-fuzz-build -func Fuzz_% -o <package>-%-fuzz.zip github.com/lightningnetwork/lnd/fuzz/<package>'
|
||||
```shell
|
||||
⛰ cd fuzz/<package>
|
||||
⛰ find * -maxdepth 1 -regex '[A-Za-z0-9\-_.]'* -not -name fuzz_utils.go | sed 's/\.go$//1' | xargs -I % sh -c 'go-fuzz-build -func Fuzz_% -o <package>-%-fuzz.zip github.com/lightningnetwork/lnd/fuzz/<package>'
|
||||
```
|
||||
|
||||
* This may take a while since this will create zip files associated with each fuzzing target.
|
||||
|
||||
* Now, run `go-fuzz` with `workdir` set as below!
|
||||
```
|
||||
$ go-fuzz -bin=<.zip archive here> -workdir=<harness> -procs=<num workers>
|
||||
```shell
|
||||
⛰ go-fuzz -bin=<.zip archive here> -workdir=<harness> -procs=<num workers>
|
||||
```
|
||||
|
||||
`go-fuzz` will print out log lines every couple of seconds. Example output:
|
||||
```
|
||||
```text
|
||||
2017/09/19 17:44:23 workers: 8, corpus: 23 (3s ago), crashers: 1, restarts: 1/748, execs: 400690 (16694/sec), cover: 394, uptime: 24s
|
||||
```
|
||||
Corpus is the number of items in the corpus. `go-fuzz` may add valid inputs to
|
||||
@ -41,7 +41,7 @@ Fuzzing generally works best with a corpus that is of minimal size while achievi
|
||||
|
||||
### Test Harness ###
|
||||
If you take a look at the test harnesses that are used, you will see that they all consist of one function:
|
||||
```
|
||||
```go
|
||||
func Fuzz(data []byte) int
|
||||
```
|
||||
If:
|
||||
|
||||
@ -21,22 +21,22 @@ Create a new `.net core` console application called `lndclient` at your root dir
|
||||
|
||||
Create a folder `Grpc` in the root of your project and fetch the lnd proto files
|
||||
|
||||
```bash
|
||||
mkdir Grpc
|
||||
curl -o Grpc/rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```shell
|
||||
⛰ mkdir Grpc
|
||||
⛰ curl -o Grpc/rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```
|
||||
|
||||
Install `Grpc.Tools`, `Google.Protobuf`, `Grpc.Core` using NuGet or manually with `dotnet add`:
|
||||
|
||||
```bash
|
||||
dotnet add package Grpc.Tools
|
||||
dotnet add package Google.Protobuf
|
||||
dotnet add package Grpc.Core
|
||||
```shell
|
||||
⛰ dotnet add package Grpc.Tools
|
||||
⛰ dotnet add package Google.Protobuf
|
||||
⛰ dotnet add package Grpc.Core
|
||||
```
|
||||
|
||||
Add the `rpc.proto` file to the `.csproj` file in an ItemGroup. (In Visual Studio you can do this by unloading the project, editing the `.csproj` file and then reloading it)
|
||||
|
||||
```
|
||||
```xml
|
||||
<ItemGroup>
|
||||
<Protobuf Include="Grpc\rpc.proto" GrpcServices="Client" />
|
||||
</ItemGroup>
|
||||
@ -48,8 +48,7 @@ You're done! Build the project and verify that it works.
|
||||
|
||||
Use the code below to set up a channel and client to connect to your `lnd` node:
|
||||
|
||||
```c#
|
||||
|
||||
```cs
|
||||
using System.Collections.Generic;
|
||||
using System.IO;
|
||||
using System.Threading.Tasks;
|
||||
@ -69,7 +68,6 @@ var cert = File.ReadAllText(<Tls_Cert_Location>);
|
||||
var sslCreds = new SslCredentials(cert);
|
||||
var channel = new Grpc.Core.Channel("localhost:10009", sslCreds);
|
||||
var client = new Lnrpc.Lightning.LightningClient(channel);
|
||||
|
||||
```
|
||||
|
||||
### Examples
|
||||
@ -78,7 +76,7 @@ Let's walk through some examples of C# `gRPC` clients. These examples assume tha
|
||||
|
||||
#### Simple RPC
|
||||
|
||||
```c#
|
||||
```cs
|
||||
// Retrieve and display the wallet balance
|
||||
// Use "WalletBalanceAsync" if in async context
|
||||
var response = client.WalletBalance(new WalletBalanceRequest());
|
||||
@ -87,7 +85,7 @@ Console.WriteLine(response);
|
||||
|
||||
#### Response-streaming RPC
|
||||
|
||||
```c#
|
||||
```cs
|
||||
var request = new InvoiceSubscription();
|
||||
using (var call = client.SubscribeInvoices(request))
|
||||
{
|
||||
@ -100,20 +98,20 @@ using (var call = client.SubscribeInvoices(request))
|
||||
```
|
||||
|
||||
Now, create an invoice for your node at `localhost:10009` and send a payment to it from another node.
|
||||
```bash
|
||||
$ lncli addinvoice --amt=100
|
||||
```shell
|
||||
⛰ lncli addinvoice --amt=100
|
||||
{
|
||||
"r_hash": <R_HASH>,
|
||||
"pay_req": <PAY_REQ>
|
||||
}
|
||||
$ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
⛰ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
```
|
||||
|
||||
Your console should now display the details of the recently satisfied invoice.
|
||||
|
||||
#### Bidirectional-streaming RPC
|
||||
|
||||
```c#
|
||||
```cs
|
||||
using (var call = client.SendPayment())
|
||||
{
|
||||
var responseReaderTask = Task.Run(async () =>
|
||||
@ -155,7 +153,7 @@ This example will send a payment of 100 satoshis every 2 seconds.
|
||||
|
||||
To authenticate using macaroons you need to include the macaroon in the metadata of the request.
|
||||
|
||||
```c#
|
||||
```cs
|
||||
// Lnd admin macaroon is at <LND_DIR>/data/chain/bitcoin/simnet/admin.macaroon on Windows
|
||||
// ~/.lnd/data/chain/bitcoin/simnet/admin.macaroon on Linux and ~/Library/Application Support/Lnd/data/chain/bitcoin/simnet/admin.macaroon on Mac
|
||||
byte[] macaroonBytes = File.ReadAllBytes("<LND_DIR>/data/chain/bitcoin/simnet/admin.macaroon");
|
||||
@ -164,13 +162,13 @@ var macaroon = BitConverter.ToString(macaroonBytes).Replace("-", ""); // hex for
|
||||
|
||||
The simplest approach to use the macaroon is to include the metadata in each request as shown below.
|
||||
|
||||
```c#
|
||||
```cs
|
||||
client.GetInfo(new GetInfoRequest(), new Metadata() { new Metadata.Entry("macaroon", macaroon) });
|
||||
```
|
||||
|
||||
However, this can get tiresome to do for each request, so to avoid explicitly including the macaroon we can update the credentials to include it automatically.
|
||||
|
||||
```c#
|
||||
```cs
|
||||
// build ssl credentials using the cert the same as before
|
||||
var sslCreds = new SslCredentials(cert);
|
||||
|
||||
|
||||
@ -11,7 +11,7 @@ with lnd in Java. We'll be using Maven as our build tool.
|
||||
|
||||
### Setup and Installation
|
||||
#### Project Structure
|
||||
```
|
||||
```text
|
||||
.
|
||||
├── pom.xml
|
||||
└── src
|
||||
@ -34,13 +34,13 @@ Note the ***proto*** folder, where all the proto files are kept.
|
||||
- [http.proto](https://github.com/grpc-ecosystem/grpc-gateway/blob/master/third_party/googleapis/google/api/http.proto)
|
||||
|
||||
#### pom.xml
|
||||
```
|
||||
```xml
|
||||
<properties>
|
||||
<grpc.version>1.8.0</grpc.version>
|
||||
</properties>
|
||||
```
|
||||
The following dependencies are required.
|
||||
```
|
||||
```xml
|
||||
<dependencies>
|
||||
<dependency>
|
||||
<groupId>io.grpc</groupId>
|
||||
@ -70,7 +70,7 @@ The following dependencies are required.
|
||||
</dependencies>
|
||||
```
|
||||
In the build section, we'll need to configure the following things :
|
||||
```
|
||||
```xml
|
||||
<build>
|
||||
<extensions>
|
||||
<extension>
|
||||
@ -184,11 +184,11 @@ public class Main {
|
||||
```
|
||||
#### Running the example
|
||||
Execute the following command in the directory where the **pom.xml** file is located.
|
||||
```
|
||||
mvn compile exec:java -Dexec.mainClass="Main" -Dexec.cleanupDaemonThreads=false
|
||||
```shell
|
||||
⛰ mvn compile exec:java -Dexec.mainClass="Main" -Dexec.cleanupDaemonThreads=false
|
||||
```
|
||||
##### Sample output
|
||||
```
|
||||
```text
|
||||
[INFO] Scanning for projects...
|
||||
[INFO] ------------------------------------------------------------------------
|
||||
[INFO] Detecting the operating system and CPU architecture
|
||||
|
||||
@ -121,7 +121,7 @@ invoice.
|
||||
|
||||
This example has a few dependencies:
|
||||
```shell
|
||||
npm install --save async lodash bytebuffer
|
||||
⛰ npm install --save async lodash bytebuffer
|
||||
```
|
||||
|
||||
You can run the following in your shell or put it in a program and run it like
|
||||
|
||||
@ -10,32 +10,32 @@ based on protocol buffers and as such, you will need to compile the lnd proto
|
||||
file in Python before you can use it to communicate with lnd.
|
||||
|
||||
1. Create a virtual environment for your project
|
||||
```
|
||||
$ virtualenv lnd
|
||||
```shell
|
||||
⛰ virtualenv lnd
|
||||
```
|
||||
2. Activate the virtual environment
|
||||
```
|
||||
$ source lnd/bin/activate
|
||||
```shell
|
||||
⛰ source lnd/bin/activate
|
||||
```
|
||||
3. Install dependencies (googleapis-common-protos is required due to the use of
|
||||
google/api/annotations.proto)
|
||||
```
|
||||
(lnd)$ pip install grpcio grpcio-tools googleapis-common-protos
|
||||
```shell
|
||||
lnd ⛰ pip install grpcio grpcio-tools googleapis-common-protos
|
||||
```
|
||||
4. Clone the google api's repository (required due to the use of
|
||||
google/api/annotations.proto)
|
||||
```
|
||||
(lnd)$ git clone https://github.com/googleapis/googleapis.git
|
||||
```shell
|
||||
lnd ⛰ git clone https://github.com/googleapis/googleapis.git
|
||||
```
|
||||
5. Copy the lnd rpc.proto file (you'll find this at
|
||||
[lnrpc/rpc.proto](https://github.com/lightningnetwork/lnd/blob/master/lnrpc/rpc.proto))
|
||||
or just download it
|
||||
```
|
||||
(lnd)$ curl -o rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```shell
|
||||
lnd ⛰ curl -o rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```
|
||||
6. Compile the proto file
|
||||
```
|
||||
(lnd)$ python -m grpc_tools.protoc --proto_path=googleapis:. --python_out=. --grpc_python_out=. rpc.proto
|
||||
```shell
|
||||
lnd ⛰ python -m grpc_tools.protoc --proto_path=googleapis:. --python_out=. --grpc_python_out=. rpc.proto
|
||||
```
|
||||
|
||||
After following these steps, two files `rpc_pb2.py` and `rpc_pb2_grpc.py` will
|
||||
@ -52,9 +52,9 @@ For example, if you want to generate the RPC modules for the `Router` subserver
|
||||
extra steps (after completing all 6 step described above) to get the
|
||||
`router_pb2.py` and `router_pb2_grpc.py`:
|
||||
|
||||
```
|
||||
(lnd)$ curl -o router.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/routerrpc/router.proto
|
||||
(lnd)$ python -m grpc_tools.protoc --proto_path=googleapis:. --python_out=. --grpc_python_out=. router.proto
|
||||
```shell
|
||||
lnd ⛰ curl -o router.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/routerrpc/router.proto
|
||||
lnd ⛰ python -m grpc_tools.protoc --proto_path=googleapis:. --python_out=. --grpc_python_out=. router.proto
|
||||
```
|
||||
|
||||
### Imports and Client
|
||||
@ -105,13 +105,13 @@ for invoice in stub.SubscribeInvoices(request):
|
||||
|
||||
Now, create an invoice for your node at `localhost:10009`and send a payment to
|
||||
it from another node.
|
||||
```bash
|
||||
$ lncli addinvoice --amt=100
|
||||
```shell
|
||||
lnd ⛰ lncli addinvoice --amt=100
|
||||
{
|
||||
"r_hash": <R_HASH>,
|
||||
"pay_req": <PAY_REQ>
|
||||
}
|
||||
$ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
lnd ⛰ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
```
|
||||
|
||||
Your Python console should now display the details of the recently satisfied
|
||||
|
||||
@ -14,27 +14,27 @@ the `lnd` proto file in Ruby before you can use it to communicate with `lnd`.
|
||||
|
||||
Install gRPC rubygems:
|
||||
|
||||
```
|
||||
$ gem install grpc
|
||||
$ gem install grpc-tools
|
||||
```shell
|
||||
⛰ gem install grpc
|
||||
⛰ gem install grpc-tools
|
||||
```
|
||||
|
||||
Clone the Google APIs repository:
|
||||
|
||||
```
|
||||
$ git clone https://github.com/googleapis/googleapis.git
|
||||
```shell
|
||||
⛰ git clone https://github.com/googleapis/googleapis.git
|
||||
```
|
||||
|
||||
Fetch the `rpc.proto` file (or copy it from your local source directory):
|
||||
|
||||
```
|
||||
$ curl -o rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```shell
|
||||
⛰ curl -o rpc.proto -s https://raw.githubusercontent.com/lightningnetwork/lnd/master/lnrpc/rpc.proto
|
||||
```
|
||||
|
||||
Compile the proto file:
|
||||
|
||||
```
|
||||
$ grpc_tools_ruby_protoc --proto_path googleapis:. --ruby_out=. --grpc_out=. rpc.proto
|
||||
```shell
|
||||
⛰ grpc_tools_ruby_protoc --proto_path googleapis:. --ruby_out=. --grpc_out=. rpc.proto
|
||||
```
|
||||
|
||||
Two files will be generated in the current directory:
|
||||
@ -98,8 +98,8 @@ end
|
||||
|
||||
Now, create an invoice on your node:
|
||||
|
||||
```bash
|
||||
$ lncli addinvoice --amt=590
|
||||
```shell
|
||||
⛰ lncli addinvoice --amt=590
|
||||
{
|
||||
"r_hash": <R_HASH>,
|
||||
"pay_req": <PAY_REQ>
|
||||
@ -108,8 +108,8 @@ $ lncli addinvoice --amt=590
|
||||
|
||||
Next send a payment to it from another node:
|
||||
|
||||
```
|
||||
$ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
```shell
|
||||
⛰ lncli sendpayment --pay_req=<PAY_REQ>
|
||||
```
|
||||
|
||||
You should now see the details of the settled invoice appear.
|
||||
|
||||
@ -146,11 +146,17 @@ To avoid leaking the macaroon information, `lnd` supports the so called
|
||||
Examples:
|
||||
|
||||
* Create a new wallet stateless (first run):
|
||||
* `lncli create --stateless_init --save_to=/safe/location/admin.macaroon`
|
||||
```shell
|
||||
⛰ lncli create --stateless_init --save_to=/safe/location/admin.macaroon
|
||||
```
|
||||
* Unlock a wallet that has previously been initialized stateless:
|
||||
* `lncli unlock --stateless_init`
|
||||
```shell
|
||||
⛰ lncli unlock --stateless_init
|
||||
```
|
||||
* Use the created macaroon:
|
||||
* `lncli --macaroonpath=/safe/location/admin.macaroon getinfo`
|
||||
```shell
|
||||
⛰ lncli --macaroonpath=/safe/location/admin.macaroon getinfo
|
||||
```
|
||||
|
||||
## Using Macaroons with GRPC clients
|
||||
|
||||
@ -158,14 +164,18 @@ When interacting with `lnd` using the GRPC interface, the macaroons are encoded
|
||||
as a hex string over the wire and can be passed to `lnd` by specifying the
|
||||
hex-encoded macaroon as GRPC metadata:
|
||||
|
||||
GET https://localhost:8080/v1/getinfo
|
||||
Grpc-Metadata-macaroon: <macaroon>
|
||||
```text
|
||||
GET https://localhost:8080/v1/getinfo
|
||||
Grpc-Metadata-macaroon: <macaroon>
|
||||
```
|
||||
|
||||
Where `<macaroon>` is the hex encoded binary data from the macaroon file itself.
|
||||
|
||||
A very simple example using `curl` may look something like this:
|
||||
|
||||
curl --insecure --header "Grpc-Metadata-macaroon: $(xxd -ps -u -c 1000 $HOME/.lnd/data/chain/bitcoin/simnet/admin.macaroon)" https://localhost:8080/v1/getinfo
|
||||
```shell
|
||||
⛰ curl --insecure --header "Grpc-Metadata-macaroon: $(xxd -ps -u -c 1000 $HOME/.lnd/data/chain/bitcoin/simnet/admin.macaroon)" https://localhost:8080/v1/getinfo
|
||||
```
|
||||
|
||||
Have a look at the [Java GRPC example](/docs/grpc/java.md) for programmatic usage details.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ the time of writing this documentation, UPnP and NAT-PMP are supported. NAT
|
||||
traversal can be enabled through `lnd`'s `--nat` flag.
|
||||
|
||||
```shell
|
||||
$ lnd ... --nat
|
||||
⛰ lnd ... --nat
|
||||
```
|
||||
|
||||
On startup, `lnd` will try the different techniques until one is found that's
|
||||
|
||||
75
docs/psbt.md
75
docs/psbt.md
@ -25,9 +25,8 @@ amounts to be in satoshis instead of fractions of a bitcoin.
|
||||
Let's start with a very simple example and assume we want to send half a coin
|
||||
to the address `bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re`:
|
||||
|
||||
```shell script
|
||||
$ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re":50000000}'
|
||||
|
||||
```shell
|
||||
⛰ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re":50000000}'
|
||||
{
|
||||
"psbt": "cHNidP8BAHECAAAAAeJQY2VLRtutKgQYFUajEKpjFfl0Uyrm6x23OumDpe/4AQAAAAD/////AkxREgEAAAAAFgAUv6pTgbKHN60CZ+RQn5yOuH6c2WiA8PoCAAAAABYAFJDbOFU0E6zFF/M+g/AKDyqI2iUaAAAAAAABAOsCAAAAAAEBbxqXgEf9DlzcqqNM610s5pL1X258ra6+KJ22etb7HAcBAAAAAAAAAAACACT0AAAAAAAiACC7U1W0iJGhQ6o7CexDh5k36V6v3256xpA9/xmB2BybTFZdDQQAAAAAFgAUKp2ThzhswyM2QHlyvmMB6tQB7V0CSDBFAiEA4Md8RIZYqFdUPsgDyomlzMJL9bJ6Ho23JGTihXtEelgCIAeNXRLyt88SOuuWFVn3IodCE4U5D6DojIHesRmikF28ASEDHYFzMEAxfmfq98eSSnZtUwb1w7mAtHG65y8qiRFNnIkAAAAAAQEfVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQEDBAEAAAAAAAA=",
|
||||
"change_output_index": 0,
|
||||
@ -51,8 +50,8 @@ If we inspect the PSBT that was created, we see that the locked input was indeed
|
||||
selected, the UTXO information was attached and a change output (at index 0) was
|
||||
created as well:
|
||||
|
||||
```shell script
|
||||
$ bitcoin-cli decodepsbt cHNidP8BAHECAAAAAeJQY2VLRtutKgQYFUajEKpjFfl0Uyrm6x23OumDpe/4AQAAAAD/////AkxREgEAAAAAFgAUv6pTgbKHN60CZ+RQn5yOuH6c2WiA8PoCAAAAABYAFJDbOFU0E6zFF/M+g/AKDyqI2iUaAAAAAAABAOsCAAAAAAEBbxqXgEf9DlzcqqNM610s5pL1X258ra6+KJ22etb7HAcBAAAAAAAAAAACACT0AAAAAAAiACC7U1W0iJGhQ6o7CexDh5k36V6v3256xpA9/xmB2BybTFZdDQQAAAAAFgAUKp2ThzhswyM2QHlyvmMB6tQB7V0CSDBFAiEA4Md8RIZYqFdUPsgDyomlzMJL9bJ6Ho23JGTihXtEelgCIAeNXRLyt88SOuuWFVn3IodCE4U5D6DojIHesRmikF28ASEDHYFzMEAxfmfq98eSSnZtUwb1w7mAtHG65y8qiRFNnIkAAAAAAQEfVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQEDBAEAAAAAAAA=
|
||||
```shell
|
||||
⛰ bitcoin-cli decodepsbt cHNidP8BAHECAAAAAeJQY2VLRtutKgQYFUajEKpjFfl0Uyrm6x23OumDpe/4AQAAAAD/////AkxREgEAAAAAFgAUv6pTgbKHN60CZ+RQn5yOuH6c2WiA8PoCAAAAABYAFJDbOFU0E6zFF/M+g/AKDyqI2iUaAAAAAAABAOsCAAAAAAEBbxqXgEf9DlzcqqNM610s5pL1X258ra6+KJ22etb7HAcBAAAAAAAAAAACACT0AAAAAAAiACC7U1W0iJGhQ6o7CexDh5k36V6v3256xpA9/xmB2BybTFZdDQQAAAAAFgAUKp2ThzhswyM2QHlyvmMB6tQB7V0CSDBFAiEA4Md8RIZYqFdUPsgDyomlzMJL9bJ6Ho23JGTihXtEelgCIAeNXRLyt88SOuuWFVn3IodCE4U5D6DojIHesRmikF28ASEDHYFzMEAxfmfq98eSSnZtUwb1w7mAtHG65y8qiRFNnIkAAAAAAQEfVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQEDBAEAAAAAAAA=
|
||||
{
|
||||
"tx": {
|
||||
"txid": "33a316d62ddf74656967754d26ea83a3cb89e03ae44578d965156d4b71b1fce7",
|
||||
@ -132,9 +131,8 @@ manually.
|
||||
The first step is to look at all available UTXOs and choose. To do so, we use
|
||||
the `listunspent` command:
|
||||
|
||||
```shell script
|
||||
$ lncli listunspent
|
||||
|
||||
```shell
|
||||
⛰ lncli listunspent
|
||||
{
|
||||
"utxos": [
|
||||
{
|
||||
@ -160,10 +158,9 @@ $ lncli listunspent
|
||||
|
||||
Next, we choose these two inputs and create the PSBT:
|
||||
|
||||
```shell script
|
||||
$ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re":50000000}' \
|
||||
```shell
|
||||
⛰ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re":50000000}' \
|
||||
--inputs='["3597b451ff56bc901eb806e8c644a004e934b4c208679756b4cddc455c768c48:1","f8efa583e93ab71debe62a5374f91563aa10a3461518042aaddb464b656350e2:1"]'
|
||||
|
||||
{
|
||||
"psbt": "cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBAwQBAAAAAAEA6wIAAAAAAQFvGpeAR/0OXNyqo0zrXSzmkvVfbnytrr4onbZ61vscBwEAAAAAAAAAAAIAJPQAAAAAACIAILtTVbSIkaFDqjsJ7EOHmTfpXq/fbnrGkD3/GYHYHJtMVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQJIMEUCIQDgx3xEhlioV1Q+yAPKiaXMwkv1snoejbckZOKFe0R6WAIgB41dEvK3zxI665YVWfcih0IThTkPoOiMgd6xGaKQXbwBIQMdgXMwQDF+Z+r3x5JKdm1TBvXDuYC0cbrnLyqJEU2ciQAAAAABAR9WXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAQMEAQAAAAAAAA==",
|
||||
"change_output_index": 1,
|
||||
@ -185,9 +182,8 @@ $ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8
|
||||
Inspecting this PSBT, we notice that the two inputs were chosen and a large
|
||||
change change output was added at index 1:
|
||||
|
||||
```shell script
|
||||
$ bitcoin-cli decodepsbt cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBAwQBAAAAAAEA6wIAAAAAAQFvGpeAR/0OXNyqo0zrXSzmkvVfbnytrr4onbZ61vscBwEAAAAAAAAAAAIAJPQAAAAAACIAILtTVbSIkaFDqjsJ7EOHmTfpXq/fbnrGkD3/GYHYHJtMVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQJIMEUCIQDgx3xEhlioV1Q+yAPKiaXMwkv1snoejbckZOKFe0R6WAIgB41dEvK3zxI665YVWfcih0IThTkPoOiMgd6xGaKQXbwBIQMdgXMwQDF+Z+r3x5JKdm1TBvXDuYC0cbrnLyqJEU2ciQAAAAABAR9WXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAQMEAQAAAAAAAA==
|
||||
|
||||
```shell
|
||||
⛰ bitcoin-cli decodepsbt cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBAwQBAAAAAAEA6wIAAAAAAQFvGpeAR/0OXNyqo0zrXSzmkvVfbnytrr4onbZ61vscBwEAAAAAAAAAAAIAJPQAAAAAACIAILtTVbSIkaFDqjsJ7EOHmTfpXq/fbnrGkD3/GYHYHJtMVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQJIMEUCIQDgx3xEhlioV1Q+yAPKiaXMwkv1snoejbckZOKFe0R6WAIgB41dEvK3zxI665YVWfcih0IThTkPoOiMgd6xGaKQXbwBIQMdgXMwQDF+Z+r3x5JKdm1TBvXDuYC0cbrnLyqJEU2ciQAAAAABAR9WXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAQMEAQAAAAAAAA==
|
||||
{
|
||||
"tx": {
|
||||
"txid": "e62356b99c3097eaa1241ff8e39b996917e66b13e4c0ccba3698982d746c3b76",
|
||||
@ -263,9 +259,8 @@ $ bitcoin-cli decodepsbt cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv
|
||||
Assuming we now want to sign the transaction that we created in the previous
|
||||
example, we simply pass it to the `finalize` sub command of the wallet:
|
||||
|
||||
```shell script
|
||||
$ lncli wallet psbt finalize cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBAwQBAAAAAAEA6wIAAAAAAQFvGpeAR/0OXNyqo0zrXSzmkvVfbnytrr4onbZ61vscBwEAAAAAAAAAAAIAJPQAAAAAACIAILtTVbSIkaFDqjsJ7EOHmTfpXq/fbnrGkD3/GYHYHJtMVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQJIMEUCIQDgx3xEhlioV1Q+yAPKiaXMwkv1snoejbckZOKFe0R6WAIgB41dEvK3zxI665YVWfcih0IThTkPoOiMgd6xGaKQXbwBIQMdgXMwQDF+Z+r3x5JKdm1TBvXDuYC0cbrnLyqJEU2ciQAAAAABAR9WXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAQMEAQAAAAAAAA==
|
||||
|
||||
```shell
|
||||
⛰ lncli wallet psbt finalize cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBAwQBAAAAAAEA6wIAAAAAAQFvGpeAR/0OXNyqo0zrXSzmkvVfbnytrr4onbZ61vscBwEAAAAAAAAAAAIAJPQAAAAAACIAILtTVbSIkaFDqjsJ7EOHmTfpXq/fbnrGkD3/GYHYHJtMVl0NBAAAAAAWABQqnZOHOGzDIzZAeXK+YwHq1AHtXQJIMEUCIQDgx3xEhlioV1Q+yAPKiaXMwkv1snoejbckZOKFe0R6WAIgB41dEvK3zxI665YVWfcih0IThTkPoOiMgd6xGaKQXbwBIQMdgXMwQDF+Z+r3x5JKdm1TBvXDuYC0cbrnLyqJEU2ciQAAAAABAR9WXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAQMEAQAAAAAAAA==
|
||||
{
|
||||
"psbt": "cHNidP8BAJoCAAAAAkiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAAAAAAA4lBjZUtG260qBBgVRqMQqmMV+XRTKubrHbc66YOl7/gBAAAAAAAAAAACgPD6AgAAAAAWABSQ2zhVNBOsxRfzPoPwCg8qiNolGtIkCAcAAAAAFgAUuvRP5r7qAvj0egDxyX9/FH+vukgAAAAAAAEA3gIAAAAAAQEr9IZcho/gV/6fH8C8P+yhNRZP+l3YuxsyatdYcS0S6AEAAAAA/v///wLI/8+yAAAAABYAFDXoRFwgXNO5VVtVq2WpaENh6blAAOH1BQAAAAAWABTcAR0NeNdDHb96kMnH5EVUcr1YwwJHMEQCIDqugtYLp4ebJAZvOdieshLi1lLuPl2tHQG4jM4ybwEGAiBeMpCkbHBmzYvljxb1JBQyVAMuoco0xIfi+5OQdHuXaAEhAnH96NhTW09X0npE983YBsHUoMPI4U4xBtHenpZVTEqpVwAAAAEBHwDh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMBCGwCSDBFAiEAuiv52IX5wZlYJqqVGsQPfeQ/kneCNRD34v5yplNpuMYCIECHVUhjHPKSiWSsYEKD4JWGAyUwQHgDytA1whFOyLclASECg7PDfGE/uURta5/R42Vso6QKmVAgYMhjWlXENkE/x+QAAQDrAgAAAAABAW8al4BH/Q5c3KqjTOtdLOaS9V9ufK2uviidtnrW+xwHAQAAAAAAAAAAAgAk9AAAAAAAIgAgu1NVtIiRoUOqOwnsQ4eZN+ler99uesaQPf8Zgdgcm0xWXQ0EAAAAABYAFCqdk4c4bMMjNkB5cr5jAerUAe1dAkgwRQIhAODHfESGWKhXVD7IA8qJpczCS/Wyeh6NtyRk4oV7RHpYAiAHjV0S8rfPEjrrlhVZ9yKHQhOFOQ+g6IyB3rEZopBdvAEhAx2BczBAMX5n6vfHkkp2bVMG9cO5gLRxuucvKokRTZyJAAAAAAEBH1ZdDQQAAAAAFgAUKp2ThzhswyM2QHlyvmMB6tQB7V0BCGwCSDBFAiEAqK7FSrqWe2non0kl96yu2+gSXGPYPC7ZjzVZEMMWtpYCIGTzCDHZhJYGPrsnBWU8o0Eyd4nBa+6d037xGFcGUYJLASECORgkj75Xu8+DTh8bqYBIvNx1hSxV7VSJOwY6jam6LY8AAAA=",
|
||||
"final_tx": "02000000000102488c765c45dccdb456976708c2b434e904a044c6e806b81e90bc56ff51b49735010000000000000000e25063654b46dbad2a04181546a310aa6315f974532ae6eb1db73ae983a5eff80100000000000000000280f0fa020000000016001490db38553413acc517f33e83f00a0f2a88da251ad224080700000000160014baf44fe6beea02f8f47a00f1c97f7f147fafba4802483045022100ba2bf9d885f9c1995826aa951ac40f7de43f9277823510f7e2fe72a65369b8c6022040875548631cf2928964ac604283e09586032530407803cad035c2114ec8b72501210283b3c37c613fb9446d6b9fd1e3656ca3a40a99502060c8635a55c436413fc7e402483045022100a8aec54aba967b69e89f4925f7acaedbe8125c63d83c2ed98f355910c316b696022064f30831d98496063ebb2705653ca341327789c16bee9dd37ef118570651824b0121023918248fbe57bbcf834e1f1ba98048bcdc75852c55ed54893b063a8da9ba2d8f00000000"
|
||||
@ -318,9 +313,8 @@ The new `--psbt` flag in the `openchannel` command starts an interactive dialog
|
||||
between `lncli` and the user. Below the command you see an example output from
|
||||
a regtest setup. Of course all values will be different.
|
||||
|
||||
```shell script
|
||||
$ lncli openchannel --node_key 03db1e56e5f76bc4018cf6f03d1bb98a7ae96e3f18535e929034f85e7f1ca2b8ac --local_amt 1234567 --psbt
|
||||
|
||||
```shell
|
||||
⛰ lncli openchannel --node_key 03db1e56e5f76bc4018cf6f03d1bb98a7ae96e3f18535e929034f85e7f1ca2b8ac --local_amt 1234567 --psbt
|
||||
Starting PSBT funding flow with pending channel ID fc7853889a04d33b8115bd79ebc99c5eea80d894a0bead40fae5a06bcbdccd3d.
|
||||
PSBT funding initiated with peer 03db1e56e5f76bc4018cf6f03d1bb98a7ae96e3f18535e929034f85e7f1ca2b8ac.
|
||||
Please create a PSBT that sends 0.01234567 BTC (1234567 satoshi) to the funding address bcrt1qh33ghvgjj3ef625nl9jxz6nnrz2z9e65vsdey7w5msrklgr6rc0sv0s08q.
|
||||
@ -347,9 +341,8 @@ The output of the last command already gave us an example command to use with
|
||||
something like "bitcoind, give me a PSBT that sends the given amount to the
|
||||
given address, choose any input you see fit":
|
||||
|
||||
```shell script
|
||||
$ bitcoin-cli walletcreatefundedpsbt [] '[{"bcrt1qh33ghvgjj3ef625nl9jxz6nnrz2z9e65vsdey7w5msrklgr6rc0sv0s08q":0.01234567}]'
|
||||
|
||||
```shell
|
||||
⛰ bitcoin-cli walletcreatefundedpsbt [] '[{"bcrt1qh33ghvgjj3ef625nl9jxz6nnrz2z9e65vsdey7w5msrklgr6rc0sv0s08q":0.01234567}]'
|
||||
{
|
||||
"psbt": "cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA",
|
||||
"fee": 0.00003060,
|
||||
@ -365,9 +358,8 @@ in fees. Fee estimation/calculation can be changed with parameters of the
|
||||
If we want to know what exactly is in this PSBT, we can look at it with the
|
||||
`decodepsbt` command:
|
||||
|
||||
```shell script
|
||||
$ bitcoin-cli decodepsbt cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA
|
||||
|
||||
```shell
|
||||
⛰ bitcoin-cli decodepsbt cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA
|
||||
{
|
||||
"tx": {
|
||||
"txid": "374504e4246a93a45b4a2c2bc31d8adc8525aa101c7b9065db6dc01c4bdfce0a",
|
||||
@ -454,9 +446,8 @@ a secondary, hardened and firewalled `lnd` instance has the corresponding
|
||||
private keys. On the watching only mode, the following command can be used to
|
||||
create the funding PSBT:
|
||||
|
||||
```shell script
|
||||
$ lncli wallet psbt fund --outputs='{"bcrt1qh33ghvgjj3ef625nl9jxz6nnrz2z9e65vsdey7w5msrklgr6rc0sv0s08q":1234567}'
|
||||
|
||||
```shell
|
||||
⛰ lncli wallet psbt fund --outputs='{"bcrt1qh33ghvgjj3ef625nl9jxz6nnrz2z9e65vsdey7w5msrklgr6rc0sv0s08q":1234567}'
|
||||
{
|
||||
"psbt": "cHNidP8BAH0CAAAAAUiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAD/////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+X7OIFAAAAABYAFNigOB6EbCLRi+Evlv4r2yJx63NxAAAAAAABAN4CAAAAAAEBK/SGXIaP4Ff+nx/AvD/soTUWT/pd2LsbMmrXWHEtEugBAAAAAP7///8CyP/PsgAAAAAWABQ16ERcIFzTuVVbVatlqWhDYem5QADh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMCRzBEAiA6roLWC6eHmyQGbznYnrIS4tZS7j5drR0BuIzOMm8BBgIgXjKQpGxwZs2L5Y8W9SQUMlQDLqHKNMSH4vuTkHR7l2gBIQJx/ejYU1tPV9J6RPfN2AbB1KDDyOFOMQbR3p6WVUxKqVcAAAABAR8A4fUFAAAAABYAFNwBHQ1410Mdv3qQycfkRVRyvVjDAQMEAQAAAAAAAA==",
|
||||
"change_output_index": 1,
|
||||
@ -476,7 +467,7 @@ Now that we have a valid PSBT that has everything but the final
|
||||
signatures/witness data, we can paste it into the prompt in `lncli` that is
|
||||
still waiting for our input.
|
||||
|
||||
```shell script
|
||||
```shell
|
||||
...
|
||||
Base64 encoded PSBT: cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA
|
||||
|
||||
@ -493,9 +484,8 @@ perhaps `bitcoind` would only know the public keys and couldn't sign for the
|
||||
transaction itself. Again, this is only an example and can't reflect all
|
||||
real-world use cases.
|
||||
|
||||
```shell script
|
||||
$ bitcoin-cli walletprocesspsbt cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA
|
||||
|
||||
```shell
|
||||
⛰ bitcoin-cli walletprocesspsbt cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAAAA
|
||||
{
|
||||
"psbt": "cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAQhrAkcwRAIgHKQbenZYvgADRd9TKGVO36NnaIgW3S12OUg8XGtSrE8CICmeaYoJ/U7Ecm+/GneY8i2hu2QCaQnuomJgzn+JAnrDASEDUBmCLcsybA5qXSRBBdZ0Uk/FQiay9NgOpv4D26yeJpAAAAA=",
|
||||
"complete": true
|
||||
@ -506,9 +496,8 @@ If you are using the two `lnd` node model as described in
|
||||
[2b](#2b-use-lnd-to-create-a-funding-transaction), you can achieve the same
|
||||
result with the following command:
|
||||
|
||||
```shell script
|
||||
$ lncli wallet psbt finalize cHNidP8BAH0CAAAAAUiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAD/////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+X7OIFAAAAABYAFNigOB6EbCLRi+Evlv4r2yJx63NxAAAAAAABAN4CAAAAAAEBK/SGXIaP4Ff+nx/AvD/soTUWT/pd2LsbMmrXWHEtEugBAAAAAP7///8CyP/PsgAAAAAWABQ16ERcIFzTuVVbVatlqWhDYem5QADh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMCRzBEAiA6roLWC6eHmyQGbznYnrIS4tZS7j5drR0BuIzOMm8BBgIgXjKQpGxwZs2L5Y8W9SQUMlQDLqHKNMSH4vuTkHR7l2gBIQJx/ejYU1tPV9J6RPfN2AbB1KDDyOFOMQbR3p6WVUxKqVcAAAABAR8A4fUFAAAAABYAFNwBHQ1410Mdv3qQycfkRVRyvVjDAQMEAQAAAAAAAA==
|
||||
|
||||
```shell
|
||||
⛰ lncli wallet psbt finalize cHNidP8BAH0CAAAAAUiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAD/////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+X7OIFAAAAABYAFNigOB6EbCLRi+Evlv4r2yJx63NxAAAAAAABAN4CAAAAAAEBK/SGXIaP4Ff+nx/AvD/soTUWT/pd2LsbMmrXWHEtEugBAAAAAP7///8CyP/PsgAAAAAWABQ16ERcIFzTuVVbVatlqWhDYem5QADh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMCRzBEAiA6roLWC6eHmyQGbznYnrIS4tZS7j5drR0BuIzOMm8BBgIgXjKQpGxwZs2L5Y8W9SQUMlQDLqHKNMSH4vuTkHR7l2gBIQJx/ejYU1tPV9J6RPfN2AbB1KDDyOFOMQbR3p6WVUxKqVcAAAABAR8A4fUFAAAAABYAFNwBHQ1410Mdv3qQycfkRVRyvVjDAQMEAQAAAAAAAA==
|
||||
{
|
||||
"psbt": "cHNidP8BAH0CAAAAAUiMdlxF3M20VpdnCMK0NOkEoETG6Aa4HpC8Vv9RtJc1AQAAAAD/////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+X7OIFAAAAABYAFNigOB6EbCLRi+Evlv4r2yJx63NxAAAAAAABAN4CAAAAAAEBK/SGXIaP4Ff+nx/AvD/soTUWT/pd2LsbMmrXWHEtEugBAAAAAP7///8CyP/PsgAAAAAWABQ16ERcIFzTuVVbVatlqWhDYem5QADh9QUAAAAAFgAU3AEdDXjXQx2/epDJx+RFVHK9WMMCRzBEAiA6roLWC6eHmyQGbznYnrIS4tZS7j5drR0BuIzOMm8BBgIgXjKQpGxwZs2L5Y8W9SQUMlQDLqHKNMSH4vuTkHR7l2gBIQJx/ejYU1tPV9J6RPfN2AbB1KDDyOFOMQbR3p6WVUxKqVcAAAABAR8A4fUFAAAAABYAFNwBHQ1410Mdv3qQycfkRVRyvVjDAQhrAkcwRAIgU3Ow7cLkKrg8BJe0U0n9qFLPizqEzY0JtjVlpWOEk14CID/4AFNfgwNENN2LoOs0C6uHgt4sk8rNoZG+VMGzOC/HASECg7PDfGE/uURta5/R42Vso6QKmVAgYMhjWlXENkE/x+QAAAA=",
|
||||
"final_tx": "02000000000101488c765c45dccdb456976708c2b434e904a044c6e806b81e90bc56ff51b497350100000000ffffffff0287d6120000000000220020bc628bb11294729d2a93f964616a73189422e754641b9279d4dc076fa07a1e1f97ece20500000000160014d8a0381e846c22d18be12f96fe2bdb2271eb73710247304402205373b0edc2e42ab83c0497b45349fda852cf8b3a84cd8d09b63565a56384935e02203ff800535f83034434dd8ba0eb340bab8782de2c93cacda191be54c1b3382fc701210283b3c37c613fb9446d6b9fd1e3656ca3a40a99502060c8635a55c436413fc7e400000000"
|
||||
@ -526,7 +515,7 @@ LOST**!
|
||||
|
||||
Let's give it to `lncli` to continue:
|
||||
|
||||
```shell script
|
||||
```shell
|
||||
...
|
||||
Base64 encoded PSBT: cHNidP8BAH0CAAAAAbxLLf9+AYfqfF69QAQuETnL6cas7GDiWBZF+3xxc/Y/AAAAAAD+////AofWEgAAAAAAIgAgvGKLsRKUcp0qk/lkYWpzGJQi51RkG5J51NwHb6B6Hh+1If0jAQAAABYAFL+6THEGhybJnOkFGSRFbtCcPOG8AAAAAAABAR8wBBAkAQAAABYAFHemJ11XF7CU7WXBIJLD/qZF+6jrAQhrAkcwRAIgHKQbenZYvgADRd9TKGVO36NnaIgW3S12OUg8XGtSrE8CICmeaYoJ/U7Ecm+/GneY8i2hu2QCaQnuomJgzn+JAnrDASEDUBmCLcsybA5qXSRBBdZ0Uk/FQiay9NgOpv4D26yeJpAAAAA=
|
||||
{
|
||||
@ -550,18 +539,18 @@ However, the `bitcoin-cli` examples from the command line can be combined into
|
||||
a single command. For example:
|
||||
|
||||
Channel 1:
|
||||
```shell script
|
||||
$ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1qywvazres587w9wyy8uw03q8j9ek6gc9crwx4jvhqcmew4xzsvqcq3jjdja":0.01000000}]'
|
||||
```shell
|
||||
⛰ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1qywvazres587w9wyy8uw03q8j9ek6gc9crwx4jvhqcmew4xzsvqcq3jjdja":0.01000000}]'
|
||||
```
|
||||
|
||||
Channel 2:
|
||||
```shell script
|
||||
$ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1q53626fcwwtcdc942zaf4laqnr3vg5gv4g0hakd2h7fw2pmz6428sk3ezcx":0.01000000}]'
|
||||
```shell
|
||||
⛰ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1q53626fcwwtcdc942zaf4laqnr3vg5gv4g0hakd2h7fw2pmz6428sk3ezcx":0.01000000}]'
|
||||
```
|
||||
|
||||
Combined command to get batch PSBT:
|
||||
```shell script
|
||||
$ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1q53626fcwwtcdc942zaf4laqnr3vg5gv4g0hakd2h7fw2pmz6428sk3ezcx":0.01000000},{"tb1qywvazres587w9wyy8uw03q8j9ek6gc9crwx4jvhqcmew4xzsvqcq3jjdja":0.01000000}]'
|
||||
```shell
|
||||
⛰ bitcoin-cli walletcreatefundedpsbt [] '[{"tb1q53626fcwwtcdc942zaf4laqnr3vg5gv4g0hakd2h7fw2pmz6428sk3ezcx":0.01000000},{"tb1qywvazres587w9wyy8uw03q8j9ek6gc9crwx4jvhqcmew4xzsvqcq3jjdja":0.01000000}]'
|
||||
```
|
||||
|
||||
### Safety warning about batch transactions
|
||||
|
||||
@ -43,7 +43,7 @@ When a new `lnd` node is created, it's given a 24-word seed phrase, called an
|
||||
The two seed formats look similar, but the only commonality they share are
|
||||
using the same default English dictionary. A valid seed phrase obtained over
|
||||
the CLI `lncli create` command looks something like:
|
||||
```
|
||||
```text
|
||||
!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!
|
||||
|
||||
---------------BEGIN LND CIPHER SEED---------------
|
||||
@ -62,7 +62,7 @@ the CLI `lncli create` command looks something like:
|
||||
|
||||
During the creation process, users are first prompted to enter a **wallet
|
||||
password**:
|
||||
```
|
||||
```text
|
||||
Input wallet password:
|
||||
Confirm wallet password:
|
||||
```
|
||||
@ -72,7 +72,7 @@ derived master private keys or public key data.
|
||||
|
||||
Users can also _optionally_ enter a second passphrase which we call the _cipher
|
||||
seed passphrase_:
|
||||
```
|
||||
```text
|
||||
Your cipher seed can optionally be encrypted.
|
||||
Input your passphrase if you wish to encrypt it (or press enter to proceed without a cipher seed passphrase):
|
||||
```
|
||||
@ -90,30 +90,30 @@ silently decrypt to a new (likely empty) wallet.
|
||||
|
||||
The initial entry point to trigger recovery of on-chain funds in the command
|
||||
line is the `lncli create` command.
|
||||
```
|
||||
```shell
|
||||
⛰ lncli create
|
||||
```
|
||||
|
||||
Next, one can enter a _new_ wallet password to encrypt any newly derived keys
|
||||
as a result of the recovery process.
|
||||
```
|
||||
```text
|
||||
Input wallet password:
|
||||
Confirm wallet password:
|
||||
```
|
||||
|
||||
Once a new wallet password has been obtained, the user will be prompted for
|
||||
their _existing_ cipher seed:
|
||||
```
|
||||
```text
|
||||
Input your 24-word mnemonic separated by spaces: ability noise lift document certain month shoot perfect matrix mango excess turkey river pitch fluid rack drill text buddy pool soul fatal ship jelly
|
||||
```
|
||||
|
||||
If a _cipher seed passphrase_ was used when the seed was created, it MUST be entered now:
|
||||
```
|
||||
```text
|
||||
Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase):
|
||||
```
|
||||
|
||||
Finally, the user has an option to choose a _recovery window_:
|
||||
```
|
||||
```text
|
||||
Input an optional address look-ahead used to scan for used keys (default 2500):
|
||||
```
|
||||
|
||||
@ -126,7 +126,7 @@ default value.
|
||||
|
||||
If all the information provided was valid, then you'll be presented with the
|
||||
seed again:
|
||||
```
|
||||
```text
|
||||
|
||||
!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!
|
||||
|
||||
@ -145,7 +145,7 @@ lnd successfully initialized!
|
||||
```
|
||||
|
||||
In `lnd`'s logs, you should see something along the lines of (irrelevant lines skipped):
|
||||
```
|
||||
```text
|
||||
[INF] LNWL: Opened wallet
|
||||
[INF] LTND: Wallet recovery mode enabled with address lookahead of 2500 addresses
|
||||
[INF] LNWL: RECOVERY MODE ENABLED -- rescanning for used addresses with recovery_window=2500
|
||||
@ -166,7 +166,8 @@ window. Depending on how old the wallet is (the cipher seed stores the wallet's
|
||||
birthday!) and how many addresses were used, the rescan may take anywhere from
|
||||
a few minutes to a few hours. To track the recovery progress, one can use the
|
||||
command `lncli getrecoveryinfo`. When finished, the following is returned,
|
||||
```
|
||||
```shell
|
||||
⛰ lncli getrecoveryinfo
|
||||
{
|
||||
"recovery_mode": true,
|
||||
"recovery_finished": true,
|
||||
@ -177,7 +178,7 @@ command `lncli getrecoveryinfo`. When finished, the following is returned,
|
||||
If the rescan wasn't able to complete fully (`lnd` was shutdown for example),
|
||||
then from `lncli unlock`, it's possible to _restart_ the rescan from where it
|
||||
left off with the `--recovery-window` argument:
|
||||
```
|
||||
```shell
|
||||
⛰ lncli unlock --recovery_window=2500
|
||||
```
|
||||
|
||||
@ -191,7 +192,7 @@ The recovery methods described above assume a clean slate for a node, so
|
||||
there's no existing UTXO or key data in the node's database. However, there're
|
||||
times when an _existing_ node may want to _manually_ rescan the chain. We have
|
||||
a command line flag for that! Just start `lnd` and add the following flag:
|
||||
```
|
||||
```shell
|
||||
⛰ lnd --reset-wallet-transactions
|
||||
```
|
||||
|
||||
@ -202,7 +203,7 @@ some older wallets).
|
||||
Just run `lnd` with the flag, unlock it, then the wallet should begin
|
||||
rescanning. An entry resembling the following will show up in the logs once it's
|
||||
complete:
|
||||
```
|
||||
```text
|
||||
[INF] LNWL: Finished rescan for 800 addresses (synced to block 3032830c812a4a6ea305d8ead13b52e9e69d6400ff3c997970b6f76fbc770920, height 748)
|
||||
```
|
||||
|
||||
@ -247,9 +248,7 @@ entries for _all_ currently open channels. Each time a channel is opened or
|
||||
closed, this file is updated on disk in a safe manner (atomic file rename). As
|
||||
a result, unlike the `channel.db` file, it's _always_ safe to copy this file
|
||||
for backup at ones desired location. The default location on Linux is:
|
||||
```
|
||||
~/.lnd/data/chain/bitcoin/mainnet/channel.backup
|
||||
```
|
||||
`~/.lnd/data/chain/bitcoin/mainnet/channel.backup`
|
||||
|
||||
An example of using file system level notification to [copy the backup to a
|
||||
distinct volume/partition/drive can be found
|
||||
@ -259,7 +258,7 @@ here](https://gist.github.com/alexbosworth/2c5e185aedbdac45a03655b709e255a3).
|
||||
|
||||
Another way to obtain SCBS for all or a target channel is via the new
|
||||
`exportchanbackup` `lncli` command:
|
||||
```
|
||||
```shell
|
||||
⛰ lncli --network=simnet exportchanbackup --chan_point=29be6d259dc71ebdf0a3a0e83b240eda78f9023d8aeaae13c89250c7e59467d5:0
|
||||
{
|
||||
"chan_point": "29be6d259dc71ebdf0a3a0e83b240eda78f9023d8aeaae13c89250c7e59467d5:0",
|
||||
@ -293,13 +292,13 @@ schemes, compared to the file system notification based approach.
|
||||
|
||||
If a node is being created from scratch, then it's possible to pass in an
|
||||
existing SCB using the `lncli create` or `lncli unlock` commands:
|
||||
```
|
||||
```shell
|
||||
⛰ lncli create -multi_file=channels.backup
|
||||
```
|
||||
|
||||
Alternatively, the `restorechanbackup` command can be used if `lnd` has already
|
||||
been created at the time of SCB restoration:
|
||||
```
|
||||
```shell
|
||||
⛰ lncli restorechanbackup -h
|
||||
NAME:
|
||||
lncli restorechanbackup - Restore an existing single or multi-channel static channel backup
|
||||
|
||||
@ -19,10 +19,12 @@ helper image.
|
||||
|
||||
To build a release, run the following commands:
|
||||
|
||||
1. `git clone https://github.com/lightningnetwork/lnd.git`
|
||||
2. `cd lnd`
|
||||
3. `git checkout <TAG> # <TAG> is the name of the next release/tag`
|
||||
4. `make docker-release tag=<TAG>`
|
||||
```shell
|
||||
⛰ git clone https://github.com/lightningnetwork/lnd.git
|
||||
⛰ cd lnd
|
||||
⛰ git checkout <TAG> # <TAG> is the name of the next release/tag
|
||||
⛰ make docker-release tag=<TAG>
|
||||
```
|
||||
|
||||
Where `<TAG>` is the name of the next release of `lnd`.
|
||||
|
||||
@ -33,10 +35,12 @@ release binaries. However, on Windows, the only way to build the release
|
||||
binaries at the moment is by using the Windows Subsystem Linux. One can build
|
||||
the release binaries following these steps:
|
||||
|
||||
1. `git clone https://github.com/lightningnetwork/lnd.git`
|
||||
2. `cd lnd`
|
||||
3. `git checkout <TAG> # <TAG> is the name of the next release/tag`
|
||||
4. `make release tag=<TAG>`
|
||||
```shell
|
||||
⛰ git clone https://github.com/lightningnetwork/lnd.git
|
||||
⛰ cd lnd
|
||||
⛰ git checkout <TAG> # <TAG> is the name of the next release/tag
|
||||
⛰ make release tag=<TAG>
|
||||
```
|
||||
|
||||
This will then create a directory of the form `lnd-<TAG>` containing archives
|
||||
of the release binaries for each supported operating system and architecture,
|
||||
|
||||
@ -44,8 +44,8 @@ The minimal configuration needed to activate the tower is `watchtower.active=1`.
|
||||
Retrieving information about your tower’s configurations can be done using
|
||||
`lncli tower info`:
|
||||
|
||||
```
|
||||
🏔 lncli tower info
|
||||
```shell
|
||||
⛰ lncli tower info
|
||||
{
|
||||
"pubkey": "03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63",
|
||||
"listeners": [
|
||||
@ -58,7 +58,9 @@ Retrieving information about your tower’s configurations can be done using
|
||||
The entire set of watchtower configuration options can be found using
|
||||
`lnd -h`:
|
||||
|
||||
```
|
||||
```shell
|
||||
⛰ lncli -h
|
||||
...
|
||||
watchtower:
|
||||
--watchtower.active If the watchtower should be active or not
|
||||
--watchtower.towerdir= Directory of the watchtower.db (default: $HOME/.lnd/data/watchtower)
|
||||
@ -66,6 +68,7 @@ watchtower:
|
||||
--watchtower.externalip= Add interfaces/ports where the watchtower can accept peer connections
|
||||
--watchtower.readtimeout= Duration the watchtower server will wait for messages to be received before hanging up on client connections
|
||||
--watchtower.writetimeout= Duration the watchtower server will wait for messages to be written before hanging up on client connections
|
||||
...
|
||||
```
|
||||
|
||||
### Listening Interfaces
|
||||
@ -83,7 +86,8 @@ Additionally, users can specify their tower’s external IP address(es) using
|
||||
`watchtower.externalip=`, which will expose the full tower URIs
|
||||
(pubkey@host:port) over RPC or `lncli tower info`:
|
||||
|
||||
```
|
||||
```shell
|
||||
⛰ lncli tower info
|
||||
...
|
||||
"uris": [
|
||||
"03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@1.2.3.4:9911"
|
||||
@ -93,8 +97,8 @@ Additionally, users can specify their tower’s external IP address(es) using
|
||||
The watchtower's URIs can be given to clients in order to connect and use the
|
||||
tower with the following command:
|
||||
|
||||
```
|
||||
🏔 lncli wtclient add 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@1.2.3.4:9911
|
||||
```shell
|
||||
⛰ lncli wtclient add 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@1.2.3.4:9911
|
||||
```
|
||||
|
||||
If the watchtower's clients will need remote access, be sure to either:
|
||||
@ -107,13 +111,14 @@ If the watchtower's clients will need remote access, be sure to either:
|
||||
Watchtowers have tor hidden service support and can automatically generate a
|
||||
hidden service on startup with the following flags:
|
||||
|
||||
```
|
||||
🏔 lnd --tor.active --tor.v3 --watchtower.active
|
||||
```shell
|
||||
⛰ lnd --tor.active --tor.v3 --watchtower.active
|
||||
```
|
||||
|
||||
The onion address is then shown in the "uris" field when queried with `lncli tower info`:
|
||||
|
||||
```
|
||||
```shell
|
||||
⛰ lncli tower info
|
||||
...
|
||||
"uris": [
|
||||
"03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@bn2kxggzjysvsd5o3uqe4h7655u7v2ydhxzy7ea2fx26duaixlwuguad.onion:9911"
|
||||
@ -135,10 +140,7 @@ chains, so setting `watchtower.towerdir=/path/to/towerdir` will yield a
|
||||
watchtower database at `/path/to/towerdir/bitcoin/mainnet/watchtower.db`.
|
||||
|
||||
On Linux, for example, the default watchtower database will be located at:
|
||||
|
||||
```
|
||||
/$USER/.lnd/data/watchtower/bitcoin/mainnet/watchtower.db
|
||||
```
|
||||
`/home/$USER/.lnd/data/watchtower/bitcoin/mainnet/watchtower.db`
|
||||
|
||||
## Configuring a Watchtower Client
|
||||
|
||||
@ -146,14 +148,14 @@ In order to set up a watchtower client, you’ll need two things:
|
||||
|
||||
1. The watchtower client must be enabled with the `--wtclient.active` flag.
|
||||
|
||||
```
|
||||
🏔 lnd --wtclient.active
|
||||
```shell
|
||||
⛰ lnd --wtclient.active
|
||||
```
|
||||
|
||||
2. The watchtower URI of an active watchtower.
|
||||
|
||||
```
|
||||
🏔 lncli wtclient add 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@1.2.3.4:9911
|
||||
```shell
|
||||
⛰ lncli wtclient add 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63@1.2.3.4:9911
|
||||
```
|
||||
|
||||
Multiple watchtowers can be configured through this method.
|
||||
@ -177,8 +179,8 @@ number of sessions currently negotiated with the watchtower added above and
|
||||
determine whether it is currently being used for backups through the
|
||||
`active_session_candidate` value.
|
||||
|
||||
```
|
||||
🏔 lncli wtclient tower 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63
|
||||
```shell
|
||||
⛰ lncli wtclient tower 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63
|
||||
{
|
||||
"pubkey": "03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63",
|
||||
"addresses": [
|
||||
@ -193,8 +195,8 @@ determine whether it is currently being used for backups through the
|
||||
To obtain information about the watchtower's sessions, users can use the
|
||||
`--include_sessions` flag.
|
||||
|
||||
```
|
||||
🏔 lncli wtclient tower --include_sessions 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63
|
||||
```shell
|
||||
⛰ lncli wtclient tower --include_sessions 03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63
|
||||
{
|
||||
"pubkey": "03281d603b2c5e19b8893a484eb938d7377179a9ef1a6bca4c0bcbbfc291657b63",
|
||||
"addresses": [
|
||||
@ -216,7 +218,8 @@ To obtain information about the watchtower's sessions, users can use the
|
||||
The entire set of watchtower client configuration options can be found with
|
||||
`lncli wtclient -h`:
|
||||
|
||||
```
|
||||
```shell
|
||||
⛰ lncli wtclient -h
|
||||
NAME:
|
||||
lncli wtclient - Interact with the watchtower client.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user