Merge pull request #673 from lightninglabs/docs-lnd

Update lnd documentation

Author: github-actions[bot]

docs/lnd/DOCKER.md

@@ -3,7 +3,8 @@
 There are two flavors of Dockerfiles available:
  - `Dockerfile`: Used for production builds. Checks out the source code from
    GitHub during build. The build argument `--build-arg checkout=v0.x.x-beta`
-   can be used to specify what git tag or commit to check out before building.
+   can be used to specify what git tag or commit to `git checkout` 
+   before building.
  - `dev.Dockerfile` Used for development or testing builds. Uses the local code
    when building and allows local changes to be tested more easily.
 
@@ -32,7 +33,7 @@ You first need to build the `lnd` docker image:
 $  docker build --tag=myrepository/lnd --build-arg checkout=v0.14.1-beta .
 ```
 
-It is recommended that you checkout the latest released tag.
+It is recommended that you check out the latest released tag.
 
 You can continue by creating and running the container:
 

docs/lnd/INSTALL.md

@@ -39,7 +39,7 @@ are released by the team. See
 [release.md for more information about reproducible builds](release.md).
 
 Finally, there is the option to build `lnd` fully manually. This requires more
-tooling to be set up first but allows to produce non-production (debug,
+tooling to be set up first but allows producing non-production (debug,
 development) builds.
 
 ## Installing a binary release
@@ -136,7 +136,7 @@ the following commands for your OS:
 <details>
   <summary>macOS</summary>
 
-  First, install [Homebrew](https://brew.sh) if you don‘t already have it.
+  First, install [Homebrew](https://brew.sh) if you don't already have it.
 
   Then
 
@@ -205,7 +205,7 @@ make install
 
 The command above will install the current _master_ branch of `lnd`. If you
 wish to install a tagged release of `lnd` (as the master branch can at times be
-unstable), then [visit then release page to locate the latest
+unstable), then [visit the 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: 
@@ -294,7 +294,7 @@ To check that `lnd` was installed properly run the following command:
 ```
 
 This command requires `bitcoind` (almost any version should do) to be available
-in the system's `$PATH` variable. Otherwise some of the tests will fail.
+in the system's `$PATH` variable. Otherwise, some tests will fail.
 
 **Command-line completion for `lncli`**
 
@@ -308,7 +308,7 @@ time of writing of this document, there are three available chain backends:
 `btcd`, `neutrino`, `bitcoind`. All including neutrino can run on mainnet with
 an out of the box `lnd` instance. We don't require `--txindex` when running
 with `bitcoind` or `btcd` but activating the `txindex` will generally make
-`lnd` run faster. Note that since version 0.13 pruned nodes are supported
+`lnd` run faster. Note that since version 0.13 pruned nodes are supported, 
 although they cause performance penalty and higher network usage.
 
 The set of arguments for each of the backend modes is as follows:
@@ -461,7 +461,7 @@ the following:
 - Make sure the config setting `-rpcserialversion` in `bitcoind` is either set
   to 1 or NOT used because bitcoind's default behaviour is already correct
   (see [bitcoin/issues/28730](https://github.com/bitcoin/bitcoin/issues/28730) 
-  for more infos). Lightning depends on segwit transactions therefore we need 
+  for more info). Lightning depends on segwit transactions therefore we need 
   the witness data when querying the bitcoind backend for transaction details.
 
 - Start `bitcoind` running against testnet, and let it complete a full sync with
@@ -541,7 +541,7 @@ document](wallet.md).
 `lnd`'s authentication system is called **macaroons**, which are decentralized
 bearer credentials allowing for delegation, attenuation, and other cool
 features. You can learn more about them in Alex Akselrod's [writeup on
-Github](https://github.com/lightningnetwork/lnd/issues/20).
+GitHub](https://github.com/lightningnetwork/lnd/issues/20).
 
 Running `lncli create` to create a wallet, will by default generate 
 the `admin.macaroon`, `read_only.macaroon`, and `macaroons.db` 
@@ -596,7 +596,7 @@ Optionally, if you'd like to have a persistent configuration between `lnd`
 launches, allowing you to simply type `lnd --bitcoin.testnet --bitcoin.active`
 at the command line, you can create an `lnd.conf`.
 
-**On MacOS, located at:**
+**On macOS, located at:**
 `/Users/<username>/Library/Application Support/Lnd/lnd.conf`
 
 **On Linux, located at:**

docs/lnd/MAKEFILE.md

@@ -10,7 +10,7 @@ $  make install
 ```
 
 The command `make check` requires `bitcoind` (almost any version should do) to
-be available in the system's `$PATH` variable. Otherwise some of the tests will
+be available in the system's `$PATH` variable. Otherwise, some tests will
 fail.
 
 Developers

docs/lnd/code_contribution_guidelines.md

@@ -56,7 +56,7 @@ not hard requirements as we will gladly accept code contributions as long as
 they follow the guidelines set forth on this page.  That said, if you don't have
 the following basic qualifications you will likely find it quite difficult to
 contribute to the core layers of Lightning. However, there are still a number
-of low hanging fruit which can be tackled without having full competency in the
+of low-hanging fruit which can be tackled without having full competency in the
 areas mentioned below. 
 
 - A reasonable understanding of bitcoin at a high level (see the
@@ -82,7 +82,7 @@ security and performance implications.
   it must follow the guidelines therein.
 - [Original Satoshi Whitepaper](https://bitcoin.org/bitcoin.pdf) - This is the white paper that started it all.  Having a solid
   foundation to build on will make the code much more comprehensible.
-- [Lightning Network Whitepaper](https://lightning.network/lightning-network-paper.pdf) - This is the white paper that kicked off the Layer 2 revolution. Having a good grasp of the concepts of Lightning will make the core logic within the daemon much more comprehensible: Bitcoin Script, off-chain blockchain protocols, payment channels, bi-directional payment channels, relative and absolute time-locks, commitment state revocations, and Segregated Witness. 
+- [Lightning Network Whitepaper](https://lightning.network/lightning-network-paper.pdf) - This is the white paper that kicked off the Layer 2 revolution. Having a good grasp of the concepts of Lightning will make the core logic within the daemon much more comprehensible: Bitcoin Script, off-chain blockchain protocols, payment channels, bidirectional payment channels, relative and absolute time-locks, commitment state revocations, and Segregated Witness. 
     - The original LN was written for a rather narrow audience, the paper may be a bit unapproachable to many. Thanks to the Bitcoin community, there exist many easily accessible supplemental resources which can help one see how all the pieces fit together from double-spend protection all the way up to commitment state transitions and Hash Time Locked Contracts (HTLCs): 
         - [Lightning Network Summary](https://lightning.network/lightning-network-summary.pdf)
         - [Understanding the Lightning Network 3-Part series](https://bitcoinmagazine.com/articles/understanding-the-lightning-network-part-building-a-bidirectional-payment-channel-1464710791) 
@@ -101,7 +101,7 @@ be recommended for newcomers to read first in order to get up to speed.
 # Development Practices
 
 Developers are expected to work in their own trees and submit pull requests when
-they feel their feature or bug fix is ready for integration into the  master
+they feel their feature or bug fix is ready for integration into the master
 branch.
 
 ## Share Early, Share Often
@@ -478,7 +478,7 @@ also likely be asked to split the commit into several smaller, and hence more
 manageable, commits.
 
 Keeping the above in mind, most small changes will be reviewed within a few
-days, while large or far reaching changes may take weeks.  This is a good reason
+days, while large or far-reaching changes may take weeks.  This is a good reason
 to stick with the [Share Early, Share Often](#share-early-share-often)
 development practice outlined above.
 
@@ -506,7 +506,7 @@ make the necessary changes.
 
 During the process of responding to review comments, we prefer that changes be
 made with [fixup commits](https://robots.thoughtbot.com/autosquashing-git-commits). 
-The reason for this is two fold: it makes it easier for the reviewer to see
+The reason for this is twofold: it makes it easier for the reviewer to see
 what changes have been made between versions (since Github doesn't easily show
 prior versions like Critique) and it makes it easier on the PR author as they
 can set it to auto squash the fix up commits on rebase.
@@ -552,7 +552,7 @@ also ping them to remind them to re-request review if needed. (default x = 3)
 To control the bot, you need to add a comment on the PR starting with 
 `!lightninglabs-deploy` followed by the command. There are 2 control types: 
 mute/unmute & cadence. Only the latest comment for each control type will be 
-used. This also means you dont need to keep adding new control comments, just 
+used. This also means you don't need to keep adding new control comments, just 
 edit the latest comment for that control type.
 
 - `!lightninglabs-deploy mute` will mute the bot on the PR completely.

docs/lnd/code_formatting_rules.md

@@ -180,8 +180,8 @@ like `require.NoErrorf()`.
 
 ### Wrapping long function definitions
 
-If one is forced to wrap lines of function arguments that exceed the 80
-character limit, then indentation must be kept on the following lines. Also,
+If one is forced to wrap lines of function arguments that exceed the 
+80-character limit, then indentation must be kept on the following lines. Also,
 lines should not end with an open parenthesis if the function definition isn't
 finished yet.
 
@@ -241,7 +241,7 @@ support the `EditorConfig` scheme (for example GoLand, GitHub, GitLab,
 VisualStudio). In addition, specific settings for Visual Studio Code are checked
 into the code base as well.
 
-Other editors (for example Atom, Nodepad++, Vim, Emacs and so on) might install
+Other editors (for example Atom, Notepad++, Vim, Emacs and so on) might install
 a plugin to understand the rules in the `.editorconfig` file.
 
-In Vim you might want to use `set colorcolumn=80`.
+In Vim, you might want to use `set colorcolumn=80`.

docs/lnd/configuring_tor.md

@@ -86,8 +86,8 @@ Tor:
       --tor.privatekeypath=                                   The path to the private key of the onion service being created
 ```
 
-There are a couple things here, so let's dissect them. The `--tor.active` flag
-allows `lnd` to route all outbound and inbound connections through Tor.
+There are a couple of things here, so let's dissect them. The `--tor.active`
+flag allows `lnd` to route all outbound and inbound connections through Tor.
 
 Outbound connections are possible with the use of the `--tor.socks` and
 `--tor.dns` arguments. The `--tor.socks` argument should point to the interface
@@ -125,7 +125,7 @@ disabled to prevent inadvertent leaks.
 ## Tor Stream Isolation
 
 Our support for Tor also has an additional privacy enhancing modified: stream
-isolation. Usage of this mode means that Tor will always use  _new circuit_ for
+isolation. Usage of this mode means that Tor will always use _new circuit_ for
 each connection. This added features means that it's harder to correlate
 connections. As otherwise, several applications using Tor might share the same
 circuit.
@@ -160,7 +160,7 @@ authentication methods (arguably, from most to least secure):
 
 In order to listen for inbound connections through Tor, an onion service must be
 created. There are two types of onion services: v2 and v3. v3 onion services
-are the latest generation of onion services and they provide a number of
+are the latest generation of onion services, and they provide a number of
 advantages over the legacy v2 onion services. To learn more about these
 benefits, see [Intro to Next Gen Onion Services](https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions).
 

docs/lnd/etcd.md

@@ -2,7 +2,7 @@
 
 With the recent introduction of the `kvdb` interface LND can support multiple
 database backends allowing experimentation with the storage model as well as
-improving robustness through eg. replicating essential data.
+improving robustness through e.g. replicating essential data.
 
 Building on `kvdb` in v0.11.0 we're adding experimental [etcd](https://etcd.io)
 support to LND. As this is an unstable feature heavily in development, it still
@@ -21,7 +21,7 @@ $  make tags="kvdb_etcd"
 The important tag is the `kvdb_etcd`, without which the binary is built without
 the etcd driver.
 
-For development it is advised to set the `GOFLAGS` environment variable to 
+For development, it is advised to set the `GOFLAGS` environment variable to 
 `"-tags=test"` otherwise `gopls` won't work on code in `channeldb/kvdb/etcd`
 directory.
 

docs/lnd/fuzz.md

@@ -9,7 +9,7 @@ It is recommended that processes be set to the number of processor cores in the
 ```shell
 $  make fuzz pkg=lnwire fuzztime=1m parallel=4
 ```
-Alternatively, individual fuzz tests can be ran manually by setting the working directory to the location of the .go file holding the fuzz tests.
+Alternatively, individual fuzz tests can be run manually by setting the working directory to the location of the .go file holding the fuzz tests.
 The go test command can only test one fuzz test at a time:
 ```shell
 $  cd lnwire
@@ -21,7 +21,7 @@ $  cd lnwire
 $  go test -list=Fuzz.*
 ```
 
-Fuzz tests can be ran as normal tests, which only runs the seed corpus:
+Fuzz tests can be run as normal tests, which only runs the seed corpus:
 ```shell
 $  cd lnwire
 $  go test -run=FuzzAcceptChannel -parallel=4

docs/lnd/grpc/java.md

@@ -63,7 +63,7 @@ The following dependencies are required.
     </dependency>
 </dependencies>
 ```
-In the build section,  we'll need to configure the following things :
+In the build section, we'll need to configure the following things:
 ```xml
 <build>
     <extensions>

docs/lnd/key_import.md

@@ -9,7 +9,7 @@ account path (`m/purpose'/coin_type'/account'`) or at the address index path
 the `WalletKit` APIs.
 
 Note that in order to follow the rest of this document and/or use the
-`WalletKit` APIs, users will need to obtain a `lnd` build compiled with the
+`WalletKit` APIs, users will need to obtain an `lnd` build compiled with the
 `walletrpc` tag. Our release builds already include this tag by default, so this
 would only be necessary when compiling from source.