Merge branch 'develop' of https://github.com/lnbook/lnbook into develop

01_introduction.asciidoc

@@ -53,7 +53,7 @@ Payment:: When value is exchanged on the Lightning Network we call this a paymen
 
 Payment Channel:: A _financial relationship_ between two nodes on the Lightning Network, typically implemented by multi-signature Bitcoin transactions that share control over bitcoin between the two Lightning nodes.
 
-On-Chain/Off-Chain:: A payment is "on-chain" if it is recorded as a transaction on the Bitcoin (or other underlying) blockchain. Payments sent via payment channels between Lightning nodes, and which are not visible in the underlying blockchain, are called "off-chain" payments.
+On-Chain vs. Off-Chain:: A payment is "on-chain" if it is recorded as a transaction on the Bitcoin (or other underlying) blockchain. Payments sent via payment channels between Lightning nodes, and which are not visible in the underlying blockchain, are called "off-chain" payments.
 
 More detailed definitions of these and many other terms can be found in the <<glossary>>. Throughout this book we will explain what these concepts mean and how these technologies actually work.
 

02_getting_started.asciidoc

@@ -62,7 +62,7 @@ Future wallets from that quadrant would let a user worry about the operational a
 
 Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run a full Lightning node (one that participates in "gossip" and creates its own map of the network for path finding and routing) you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity.
 
-The category "Third-party Ligntning Nodes" can again be subdivided into:
+The category "Third-party Lightning Nodes" can again be subdivided into:
 
 - Lightweight: means that the Lightning Node is operated by a third party and that the wallet obtains the required information through an API that connects wallet and third-party LN node.
 - None: means that not only is the Lightning Node operated by a third party but most of the wallet is operated by a third party in the cloud such that the wallet does not even need to make calls on a Lightning node API.

03_how_ln_works.asciidoc

@@ -340,7 +340,7 @@ How do you not catch a cheat? If you don't do any of the above you will be vulne
 
 Every payment on the Lightning Network starts with a person who wants to receive bitcoins issuing an invoice.
 An invoice is nothing more than a simple payment instruction containing various pieces of information such as a unique payment identifier, called a payment hash, a recipient, an amount, etc.
-The main reason for this process is that it helps to make the payment process over a path of payement channels atomic.
+The main reason for this process is that it helps to make the payment process over a path of payment channels atomic.
 Atomic means that no node on the path can decide to take the money that is being routed or stop the routing process.
 The payment will either be transferred successfully through the complete path of nodes or will not be delivered at all.
 There are no such things as a partial payment or a half successful payment.
@@ -446,7 +446,7 @@ This includes currently known public payment channels, known nodes, known topolo
 
 If the sending node of a payment has selected a path that is supposed to be used to make the payment, the Lightning Network uses an onion routing scheme similar to the famous TOR-network.
 The routing scheme is called the "SPHINX mixformat" and will be explained in detail in a later chapter.
-Note that Lightning Onion routing via "SPHINX mixformat" is only similar to the TOR network routing in conecpt, but as a protocol as well as in implementation it is definitely different from the TOR network.
+Note that Lightning Onion routing via "SPHINX mixformat" is only similar to the TOR network routing in concept, but as a protocol as well as in implementation it is definitely different from the TOR network.
 For now we want to focus on its properties for the transport of payments.
 A payment package used for routing is called an "onion".
 footnote:[The term "onion" was originally used by the TOR project.
@@ -492,7 +492,7 @@ This makes the Payment Hash obtainable without the need to decrypt any onion.
 In stark contrast to the Internet Protocol Forwarding Algorithm on the lightning network it is only the sender of a payment that decides the path it takes to the recipient.
 Forwarding nodes can only reject a path.
 This can happen either on purpose or because they are not able to fulfill the request. 
-The payment forwarding algorithm is initated by the sender of an payment who selects a path throught the lightning network and constructs an onion.
+The payment forwarding algorithm is initiated by the sender of an payment who selects a path throught the lightning network and constructs an onion.
 It contains information about the payment for the recipient, routing hints for the intermediary nodes.
 Routing fees which those nodes will earn if (and only if) the payment is successfully delivered and settles with the release of the `Payment Hash` are also included to the onion.
 
@@ -500,11 +500,11 @@ All Lightning Nodes must follow the payment forwarding algorithm.
 Upon receiving a Lightning Message called `update_add_htlc` which contains the `Payment Hash` and the onion package it needs to follow through X steps:
 
 1. It needs to decrypt the outer layer of the onion and use the HMAC to make sure that the onion was not corrupted.
-2. It will check that it can fullfill the routing hints in the way that the fees are respecting its fee announcements and that it has enough liquidity on the outgoing channel or is even owner of the specified channel.
+2. It will check that it can fulfill the routing hints in the way that the fees are respecting its fee announcements and that it has enough liquidity on the outgoing channel or is even owner of the specified channel.
 3. It needs to work with its peer on the incoming channel to update the channel state to include the offered HTLC.
 4. It will have to add some padding data to the end of the onion to keep it as a constant size even though it removed some data from the beginning.
 5. It will then follow the routing hints from its layer of the onion to forward the modified onion package on its outgoing payment channel by also sending and `update_add_htlc` message which includes the same `Payment Hash` and the onion.
-6. Obviously it also has to collaborate with its peer on the outgoing channel to move foward the state to also include the offered `HTLC`.
+6. Obviously it also has to collaborate with its peer on the outgoing channel to move forward the state to also include the offered `HTLC`.
 
 Of course those steps will be interrupted and aborted if an error is detected.
 In most of those cases an error message will be send back to the originator of the received `update_add_htlc` message. 
@@ -521,11 +521,11 @@ Nodes that are sending back an error Onion must on their way remove the HTLCs fr
 [Note]
 ====
 It is important to understand that HTLCs have a time measured in absolute blockheight through which they are valid.
-Once the sender of a payment sends away the onion it is completely out if their controll what happens.
+Once the sender of a payment sends away the onion it is completely out if their control what happens.
 Honest nodes SHOULD either forward the onion as quickly as possible or send an error back the original.
 While sender expects nodes along the path to be honest it has according to the protocol no power of making sure that nodes act quickly.
 Thus payment can currently get stuck if nodes want to behave malicously. 
-While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initate another payment attempt along a different path before the onion returned with an error as a node might just have delayed the forwarding of the payment.
+While the likelihood for a payment to fail is pretty high if it does not settle quickly a node SHOULD never initiate another payment attempt along a different path before the onion returned with an error as a node might just have delayed the forwarding of the payment.
 Nodes which act malicously by delaying the forwarding of payments or errors are actually hard to detect due to the privacy properties that are gained with the onion routing scheme. 
 ====
 
@@ -551,7 +551,7 @@ This makes development a little bit tricky as one cannot easily monitor one's ow
 As long as a person follows the protocol and has their node secured, there is no major risk of losing funds when participating in the Lightning Network.
 However, there is the cost of paying on-chain fees when opening a channel.
 Any cost should come with a corresponding benefit.
-In our case the reward for Alice for bearing the cost of opening a chennel is that Alice can send and receive payments of bitcoin on the Lightning Network at any time and that she can earn fees in bitcoin by forwarding payments for other people.
+In our case the reward for Alice for bearing the cost of opening a channel is that Alice can send and receive payments of bitcoin on the Lightning Network at any time and that she can earn fees in bitcoin by forwarding payments for other people.
 Alice knows that in theory Bob can close the channel immediately after opening resulting in on-chain closing fees for Alice. 
 Alice will need to have a small amount of trust in Bob. 
 Alice has been to Bob's Cafe and clearly Bob is interested in selling her coffee, so Alice can trust Bob in this sense. 
@@ -659,7 +659,7 @@ In practical terms, instant settlement means that payments take on the order of
 And as on Bitcoin, Lightning payments are not reversible.
 When the channel is closed, a transaction will be made on the Bitcoin network and, only once that transaction is confirmed will the channel be considered closed.
 
-==== Sending arbitrary Amounts vs Capacity Restrictions
+==== Sending Arbitrary Amounts vs Capacity Restrictions
 
 On the Bitcoin network, a user can send any amount of bitcoin that they own to another user, without capacity restrictions.
 

code/docker/bitcoind/Dockerfile

@@ -1,12 +1,7 @@
 FROM ubuntu:18.04 AS bitcoind-base
 
-# RUN apk update \
-# 	&& apk upgrade \
-# 	&& apk add bash bash-completion
-
-RUN apt update \
-	&& apt install -y \
-		bash-completion
+RUN apt update && apt install -yqq \
+	curl gosu jq bash-completion
 
 ENV BITCOIND_VERSION 0.20.0
 # Install binaries for Bitcoin Core
@@ -24,12 +19,16 @@ ADD $GH_URL/contrib/bitcoin-cli.bash-completion $BC/bitcoin-cli
 ADD $GH_URL/contrib/bitcoind.bash-completion $BC/bitcoind
 ADD $GH_URL/contrib/bitcoin-tx.bash-completion $BC/bitcoin-tx
 
-ADD bashrc /root/.bashrc
-
 FROM bitcoind-base AS bitcoind-regtest
 
 ADD bitcoind /bitcoind
-RUN ln -s /bitcoind /root/.bitcoin
+RUN ln -s /bitcoind /root/.
+
+ADD bashrc /root/.bashrc
+ADD bitcoind-entrypoint.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/bitcoind-entrypoint.sh
+ADD mine.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/mine.sh
 
 # bitcoind P2P
 EXPOSE 18444/tcp
@@ -41,5 +40,7 @@ EXPOSE 12005/tcp
 EXPOSE 12006/tcp
 
 WORKDIR /bitcoind
-CMD /bin/bash /bitcoind/bitcoind-start.sh \
-	&& /bin/bash /bitcoind/mine.sh
+ENTRYPOINT ["/usr/local/bin/bitcoind-entrypoint.sh"]
+
+# Mine new block every 10 seconds
+CMD ["/usr/local/bin/mine.sh"]

code/docker/bitcoind/bashrc

@@ -1,3 +1,5 @@
 # Use bash-completion, if available
+alias bitcoin-cli="bitcoin-cli -datadir=/bitcoind"
+
 [[ $PS1 && -f /usr/share/bash-completion/bash_completion ]] && \
     . /usr/share/bash-completion/bash_completion

code/docker/bitcoind/bitcoind-entrypoint.sh

@@ -1,7 +1,13 @@
 #!/bin/bash
+set -Eeuo pipefail
 
+echo Starting bitcoind...
 bitcoind -datadir=/bitcoind -daemon
-sleep 5
+until bitcoin-cli -datadir=/bitcoind getblockchaininfo  > /dev/null 2>&1
+do
+	sleep 1
+done
+echo bitcoind started
 export address=`cat /bitcoind/keys/demo_address.txt`
 export privkey=`cat /bitcoind/keys/demo_privkey.txt`
 echo "================================================"
@@ -10,3 +16,7 @@ echo "Bitcoin address: " ${address}
 echo "Private key: " ${privkey}
 echo "================================================"
 bitcoin-cli -datadir=/bitcoind importprivkey $privkey
+
+# Executing CMD
+echo "$@"
+exec "$@"

code/docker/bitcoind/mine.sh

@@ -1,4 +1,5 @@
 #!/bin/bash
+set -Eeuo pipefail
 
 export address=`cat /bitcoind/keys/demo_address.txt`
 export privkey=`cat /bitcoind/keys/demo_privkey.txt`
@@ -14,3 +15,6 @@ while sleep 10; do \
 	bitcoin-cli -datadir=/bitcoind generatetoaddress 1 $address; \
 	echo "Balance:" `bitcoin-cli -datadir=/bitcoind getbalance`; \
 done
+
+# If loop is interrupted, stop bitcoind
+bitcoin-cli -datadir=/bitcoind stop

code/docker/btc-explorer/Dockerfile

@@ -1,5 +0,0 @@
-FROM node:12-alpine
-
-WORKDIR /usr/src/btc-explorer
-
-RUN npm install git+https://git@github.com/janoside/btc-rpc-explorer.git

code/docker/c-lightning-base/Dockerfile

@@ -1,25 +0,0 @@
-FROM ubuntu:18.04
-
-# Install development tools prerequisites
-RUN apt-get update && apt-get install -y \
-    build-essential \
-	libtool \
-	autotools-dev \
-	automake \
-	pkg-config \
-	python3 \
-	wget \
-	git \
-	curl \
-	unzip
-
-
-# Install software-properties-common to add apt repositories
-RUN apt-get install -y \
-	software-properties-common
-
-
-# c-lightning
-RUN add-apt-repository -u ppa:lightningnetwork/ppa
-RUN apt-get install -y \
- 	lightningd

code/docker/c-lightning/Dockerfile

@@ -0,0 +1,29 @@
+FROM lnbook/bitcoind-regtest AS c-lightning-base
+
+# Install software-properties-common to add apt repositories
+RUN apt update && apt install -yqq \
+	software-properties-common
+
+# c-lightning
+RUN add-apt-repository -u ppa:lightningnetwork/ppa
+RUN apt-get install -yqq \
+ 	lightningd
+
+ADD https://raw.githubusercontent.com/ElementsProject/lightning/master/contrib/lightning-cli.bash-completion /usr/share/bash-completion/completions/lightning-cli
+
+FROM c-lightning-base AS c-lightning-run
+
+ADD lightningd /lightningd
+WORKDIR /lightningd
+RUN ln -s /lightningd /root/.lightning
+
+ADD bashrc /root/.bashrc
+ADD c-lightning-entrypoint.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/c-lightning-entrypoint.sh
+ADD fund-c-lightning.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/fund-c-lightning.sh
+ADD logtail.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/logtail.sh
+
+EXPOSE 9735 9835
+ENTRYPOINT ["/usr/local/bin/c-lightning-entrypoint.sh"]

code/docker/c-lightning/bashrc

@@ -0,0 +1,4 @@
+alias lightning-cli="lightning-cli --network regtest --lightning-dir=/lightningd"
+
+[[ $PS1 && -f /usr/share/bash-completion/bash_completion ]] && \
+    . /usr/share/bash-completion/bash_completion

code/docker/c-lightning/c-lightning-entrypoint.sh

@@ -0,0 +1,16 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+lightningd --lightning-dir=/lightningd --daemon
+
+until lightning-cli --lightning-dir=/lightningd --network regtest getinfo > /dev/null 2>&1
+do
+	sleep 1
+done
+echo "Startup complete"
+sleep 2
+echo "Funding c-lightning wallet"
+source /usr/local/bin/fund-c-lightning.sh
+
+echo "$@"
+exec "$@"

code/docker/c-lightning/fund-c-lightning.sh

@@ -0,0 +1,22 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+# Generate a new receiving address for LND wallet
+address=$(lightning-cli --lightning-dir=/lightningd --network regtest newaddr | jq .address)
+
+# Ask Bitcoin Core to send 10 BTC to the address, using JSON-RPC call
+curl --user regtest:regtest \
+     -H 'content-type: text/plain;' \
+	 http://bitcoind:18443/ \
+	 --data-binary @- <<EOF
+	{
+	  "jsonrpc": "1.0",
+	  "id": "c-lightning-container",
+	  "method": "sendtoaddress",
+	  "params": [
+	    ${address},
+	    10,
+	    "funding c-lightning"
+	  ]
+	}
+EOF

code/docker/c-lightning/lightningd/config

@@ -0,0 +1,9 @@
+network=regtest
+
+bitcoin-rpcuser=regtest
+bitcoin-rpcpassword=regtest
+bitcoin-rpcconnect=bitcoind
+bitcoin-rpcport=18443
+
+log-level=debug
+log-file=/lightningd/lightningd.log

code/docker/c-lightning/logtail.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+# Show LND log from beginning and follow
+tail -n +1 -f /lightningd/lightningd.log || true

code/docker/eclair-base/Dockerfile

@@ -1,6 +0,0 @@
-FROM openjdk:11
-
-# eclair-node
-RUN mkdir -p /usr/src/eclair
-WORKDIR /usr/src/eclair
-RUN curl -SLO https://github.com/ACINQ/eclair/releases/download/v0.3.3/eclair-node-0.3.3-12ac145.jar

code/docker/eclair/Dockerfile

@@ -0,0 +1,30 @@
+FROM ubuntu:18.04 AS eclair-base
+
+RUN apt update && apt install -yqq \
+	curl gosu jq bash-completion
+
+RUN apt update && apt install -yqq \
+	openjdk-11-jdk unzip
+
+# Install eclair
+ENV ECLAIR_VER 0.4
+ENV ECLAIR_COMMIT 69c538e
+WORKDIR /usr/src
+RUN curl -sLO https://github.com/ACINQ/eclair/releases/download/v${ECLAIR_VER}/eclair-node-${ECLAIR_VER}-${ECLAIR_COMMIT}-bin.zip \
+	&& unzip eclair-node-${ECLAIR_VER}-${ECLAIR_COMMIT}-bin.zip \
+	&& install eclair-node-${ECLAIR_VER}-${ECLAIR_COMMIT}/bin/eclair-cli /usr/local/bin
+
+ADD https://raw.githubusercontent.com/ACINQ/eclair/master/contrib/eclair-cli.bash-completion /usr/share/bash-completion/completions/eclair-cli
+
+ADD eclair /eclair
+WORKDIR /eclair
+RUN ln -s /eclair /root/.eclair
+
+ADD bashrc /root/.bashrc
+ADD eclair-entrypoint.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/eclair-entrypoint.sh
+ADD logtail.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/logtail.sh
+
+EXPOSE 9735
+ENTRYPOINT ["/usr/local/bin/eclair-entrypoint.sh"]

code/docker/eclair/bashrc

@@ -0,0 +1,4 @@
+alias eclair-cli="eclair-cli -p eclair"
+
+[[ $PS1 && -f /usr/share/bash-completion/bash_completion ]] && \
+    . /usr/share/bash-completion/bash_completion

code/docker/eclair/eclair-entrypoint.sh

@@ -0,0 +1,18 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+echo Starting eclair...
+cd /usr/src/eclair-node-${ECLAIR_VER}-${ECLAIR_COMMIT}/
+/bin/bash bin/eclair-node.sh -Declair.datadir="/eclair" &
+cd /eclair
+
+until eclair-cli -p eclair getinfo  > /dev/null 2>&1
+do
+	sleep 1
+done
+
+echo Eclair node started
+
+# Executing CMD
+echo "$@"
+exec "$@"

code/docker/eclair/eclair/eclair.conf

@@ -0,0 +1,26 @@
+eclair {
+
+  chain = "regtest"
+  server {
+    public-ips = [] // external ips, will be announced on the network
+    binding-ip = "0.0.0.0"
+    port = 9735
+  }
+
+  api {
+    enabled = true // disabled by default for security reasons
+    binding-ip = "0.0.0.0"
+    port = 8080
+    password = "eclair" // password for basic auth, must be non empty if json-rpc api is enabled
+  }
+  watcher-type = "bitcoind" // other *experimental* values include "electrum"
+
+  bitcoind {
+    host = "bitcoind"
+    rpcport = 18443
+    rpcuser = "regtest"
+    rpcpassword = "regtest"
+    zmqblock = "tcp://bitcoind:12005"
+    zmqtx = "tcp://bitcoind:12006"
+  }
+}

code/docker/eclair/logtail.sh

@@ -0,0 +1,5 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+# Show LND log from beginning and follow
+tail -n +1 -f /eclair/eclair.log || true

code/docker/lnbook-app/docker-compose.yml

@@ -1,18 +1,72 @@
 version: "3.3"
+networks:
+  lnnet:
+
 services:
-  bitcoind-regtest:
-      container_name: bitcoind
-      build:
-        context: ../bitcoind-regtest/.
-        dockerfile: ./Dockerfile
-      image: lnbook/bitcoind-regtest:latest
-      ports:
-      - "18443:18443"
-      - "12005:12005"
-      - "12006:12006"
-  lnd-run:
-      container_name: lnd
-      build:
-        context: ../lnd-run
-        dockerfile: ./Dockerfile
-      image: lnbook/lnd-run:latest
+  bitcoind:
+    container_name: bitcoind
+    build:
+        context: ../bitcoind
+    image: lnbook/bitcoind:latest
+    networks:
+      - lnnet
+    expose:
+      - "18443"
+      - "12005"
+      - "12006"
+    healthcheck:
+      test: bitcoin-cli -datadir=/bitcoind getblockchaininfo
+      interval: 2s
+      timeout: 5s
+      retries: 30
+
+  Alice:
+    container_name: Alice
+    build:
+        context: ../lnd
+    image: lnbook/lnd:latest
+    depends_on:
+      - bitcoind
+    networks:
+      - lnnet
+    expose:
+      - "9735"
+
+  Bob:
+    container_name: Bob
+    build:
+      context: ../c-lightning
+    image: lnbook/c-lightning:latest
+    depends_on:
+      - bitcoind
+      - Alice
+    networks:
+      - lnnet
+    expose:
+      - "9735"
+
+  Wei:
+    container_name: Wei
+    build:
+        context: ../eclair
+    image: lnbook/eclair:latest
+    depends_on:
+      - bitcoind
+      - Bob
+    networks:
+      - lnnet
+    expose:
+      - "9735"
+
+  Gloria:
+    container_name: Gloria
+    build:
+        context: ../lnd
+    image: lnbook/lnd:latest
+    depends_on:
+      - bitcoind
+      - Wei
+    networks:
+      - lnnet
+    expose:
+      - "9735"

code/docker/lnd-run/bashrc

@@ -1 +0,0 @@
-alias lncli="lncli --lnddir=/lnd -n regtest"

code/docker/lnd/Dockerfile

@@ -3,15 +3,22 @@ FROM golang:1.13 as lnd-base
 ENV GOPATH /go
 WORKDIR $GOPATH/src
 
-RUN apt update && apt install -y \
-	jq
-
 # LND
 RUN go get -d github.com/lightningnetwork/lnd
 WORKDIR $GOPATH/src/github.com/lightningnetwork/lnd
 RUN make && make install
 
-FROM lnd-base AS lnd-run
+FROM ubuntu:18.04 AS lnd-run
+
+RUN apt update && apt install -yqq \
+	curl gosu jq bash-completion
+
+COPY --from=lnd-base /go /go
+RUN cp /go/src/github.com/lightningnetwork/lnd/contrib/lncli.bash-completion \
+	   /usr/share/bash-completion/completions/lncli
+
+ENV GOPATH /go
+ENV PATH $PATH:$GOPATH/bin
 
 ADD lnd /lnd
 RUN ln -s /lnd /root/.lnd
@@ -20,9 +27,17 @@ RUN chmod +x /usr/local/bin/fund-lnd.sh
 ADD bashrc /root/.bashrc
 ADD lnd-entrypoint.sh /usr/local/bin
 RUN chmod +x /usr/local/bin/lnd-entrypoint.sh
+ADD logtail.sh /usr/local/bin
+RUN chmod +x /usr/local/bin/logtail.sh
+
+# LND RPC
+EXPOSE 10009/tcp
+
+# LND P2P
+EXPOSE 9735/tcp
 
 WORKDIR /lnd
 ENTRYPOINT ["/usr/local/bin/lnd-entrypoint.sh"]
 
 # Show lnd logs from beginning and keep following
-CMD ["tail", "-n", "+1", "-f", "/lnd/logs/bitcoin/regtest/lnd.log"]
+CMD ["/usr/local/bin/logtail.sh"]

code/docker/lnd/bashrc

@@ -0,0 +1,4 @@
+alias lncli="lncli --lnddir=/lnd -n regtest"
+
+[[ $PS1 && -f /usr/share/bash-completion/bash_completion ]] && \
+    . /usr/share/bash-completion/bash_completion

code/docker/lnd/fund-lnd.sh

@@ -1,4 +1,5 @@
 #!/bin/bash
+set -Eeuo pipefail
 
 # Generate a new receiving address for LND wallet
 address=$(lncli --lnddir=/lnd --network regtest newaddress np2wkh | jq .address)

code/docker/lnd/lnd-entrypoint.sh

@@ -1,8 +1,9 @@
 #!/bin/bash
+set -Eeuo pipefail
 
 echo Starting lnd...
 lnd --lnddir=/lnd --noseedbackup > /dev/null &
-sleep 5
+
 until lncli --lnddir=/lnd -n regtest getinfo > /dev/null 2>&1
 do
 	sleep 1
@@ -11,4 +12,5 @@ echo "Startup complete"
 echo "Funding lnd wallet"
 source /usr/local/bin/fund-lnd.sh
 
+echo "$@"
 exec "$@"

code/docker/lnd/logtail.sh

@@ -0,0 +1,8 @@
+#!/bin/bash
+set -Eeuo pipefail
+
+# Show LND log from beginning and follow
+tail -n +1 -f /lnd/logs/bitcoin/regtest/lnd.log || true
+
+# When tail is interrupted, shutdown LND
+lncli --lnddir=/lnd --network regtest stop

node_client.asciidoc

@@ -134,7 +134,7 @@ Installing a full Bitcoin node and synching the Bitcoin blockchain is outside th
 
 A Bitcoin node can also be operated in _regtest_ mode, where the node creates a local simulated Bitcoin blockchain for testing purposes. In the following examples, we will be using regtest mode to allow us to demonstrate lightning without having to synchronize a Bitcoin node, or risk any funds.
 
-There are two docker containers for Bitcoin Core. The first is a base container (+bitcoind-base+) that downloads and installs the Bitcoin Core software. The second container (which extends the bitcoind-base container) is +bitcoind-regtest+ that runs Bitcoin Core in regtest mode and mines a new block every 10 seconds.
+The container for Bitcoin Core is +bitcoind-regtest+ that runs Bitcoin Core in regtest mode and mines a new block every 10 seconds. It's RPC port is exposed on port 18443 and accessible for RPC calls with the username +regtest+ and the password +regtest+. You can also access it with an interactive shell and run +bitcoin-cli+ commands locally.
 
 === c-lightning