Merge branch 'node_operations_chapter' into develop

node_operations.asciidoc

@@ -325,6 +325,28 @@ include::code/docker/bitcoind/bitcoind/bitcoin.conf[]
 
 That particular configuration file configures Bitcoin Core for operation as a +regtest+ node and provides a weak username and password for remote access, so you shouldn't use it for your node configuration. However, it serves to illustrate the syntax of a configuration file and you can make adjustments to it in the docker container to experiment with different options. See if you can use the +bitcoind -help+ command to understand what each of the options does in the context of the docker network we build in <<set_up_a_lightning_node>>
 
+Often, the defaults suffice and with a few modifications, your node software can be configured quickly. To get a Bitcoin Core node running for example, you only need four lines of configuration:
+
+----
+server=1
+daemon=1
+txindex=1
+rpcuser=USERNAME
+rpcpassword=PASSWORD
+----
+
+Even the +txindex+ option is not strictly necessary, though it will ensure your Bitcoin node creates an index of all transactions, which is required for some applications. The +txindex+ option is not required to run a Lightning node.
+
+A c-lightning Lightning node running on the same server also only requires a few lines in the configuration:
+
+----
+network=mainnet
+bitcoin-rpcuser=USERNAME
+bitcoin-rpcpassword=PASSWORD
+----
+
+In general, it is a good idea to minimize the amount of customization of these systems. The default configuration is carefully designed to support the most common deployments. If you modify a default value, it may cause problems later on, or reduce the performance of your node. So, modify only when necessary!
+
 ==== Security and authentication
 
 A Lightning node is, by definition, a hot-wallet. That means that the funds (both on-chain and off-chain) controlled by a Lightning node are directly controlled by keys that are loaded in the node's memory. If a Lightning node is compromised, it is trivial to create on-chain or off-chain transactions to drain its funds. It is therefore critically important that you protect it from unauthorized access, by setting up strong authentication.
@@ -333,17 +355,21 @@ Your Lightning node will expose a Remote Procedure Call (RPC) Application Progra
 
 For example, LND uses macaroons to grant access to the RPC API. By default the LND software creates three macaroons with different levels of access, called +admin+, +invoice+ and +readonly+. Depending on which macaroon you copy and use in your RPC client, you either have "readonly" access, "invoice" access (which includes the "readonly" capabilities), or "admin" access which gives you full control. There's also a macaroon "bakery" function in LND that can construct macaroons with any combination of capabilities with very fine-grained control.
 
+If you use a username/password authentication model, make sure you select a long and random password. You will not have to type this password often as it will be stored in the configuration files. You can therefore pick one that cannot be guessed. Many of the examples you will see include poorly chosen passwords and often people copy these into their own systems, giving an easy backdoor to anyone. Don't do that. Use a password manager to generate a random alpha-numeric password. Since certain special characters can interfere with the command line (e.g. $/!*\&%), it is best to avoid them for passwords that will be used in a shell environment and may end up being passed as command-line parameters.
 
+A plain alphanumeric sequence that is longer than 12 characters and randomly generated is usually sufficient. If you plan to store large amount of money on your Lightning node and are concerned about remote brute-force attacks, select a length of more than 20 characters that makes such attacks practically infeasible.
 
-==== NEXT ...
+=== Node and channel backups
 
-* Logging
-* Process monitoring
+A very important consideration when running a Lightning node is the issue of backups. Unlike a Bitcoin wallet, where a BIP39 mnemonic phrase can recover all the state of the wallet, in Lightning this is not sufficient.
 
-=== Node and channel backups
+Lightning wallets do use a BIP39 mnemonic phrase backup for the on-chain wallet. However, due to the way channels are constructed, the mnemonic phrase is not sufficient to restore a Lightning node. An additional layer of backup is needed, which is called the _Channel State Backup (CSB)_. Without a CSB, a Lightning node operator may lose all the funds that are in channels if they lose the Lightning node data store.
+
+[WARNING]
+====
+Do not fund channels until you have created a system to continuously backup your channel state. Your backups should be moved "offsite" to a different system and location from your node, so that they can survive a variety of system failures (power loss, data corruption etc.) or natural disasters (flood, fire etc.)
+====
 
-* Difference between Bitcoin wallet (BIP39) backups and LN backups
-* Need for backup of channel state
 
 ==== Static channel backups