From e6dca0ce6ea355b4f56b64a2be151f3e719f3dd5 Mon Sep 17 00:00:00 2001 From: Marcia Waite Date: Mon, 15 Jul 2024 00:59:00 -0700 Subject: [PATCH] multi: Fix typos and grammar in multiple docs --- .github/pull_request_template.md | 4 ++-- README.md | 2 +- aezeed/README.md | 6 +++--- docker/README.md | 8 +++---- docs/DOCKER.md | 5 +++-- docs/INSTALL.md | 16 +++++++------- docs/MAKEFILE.md | 2 +- docs/code_contribution_guidelines.md | 12 +++++------ docs/code_formatting_rules.md | 8 +++---- docs/configuring_tor.md | 8 +++---- docs/etcd.md | 4 ++-- docs/fuzz.md | 4 ++-- docs/grpc/java.md | 2 +- docs/key_import.md | 2 +- docs/macaroons.md | 2 +- docs/postgres.md | 2 +- docs/psbt.md | 6 +++--- docs/recovery.md | 8 +++---- docs/release-notes/release-notes-0.14.0.md | 2 +- docs/release.md | 4 ++-- docs/remote-signing.md | 4 ++-- docs/rest/websockets.md | 6 +++--- docs/safety.md | 25 +++++++++++----------- docs/wallet.md | 4 ++-- docs/watchtower.md | 2 +- lntest/README.md | 4 ++-- macaroons/README.md | 2 +- mobile/README.md | 2 +- sweep/README.md | 6 +++--- 29 files changed, 81 insertions(+), 81 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 6520dcfd6..d2ca2a4d5 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -15,6 +15,6 @@ Steps for reviewers to follow to test the change. - [ ] Commits follow the [Ideal Git Commit Structure](https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md#IdealGitCommitStructure). - [ ] Any new logging statements use an appropriate subsystem and logging level. - [ ] Any new lncli commands have appropriate tags in the comments for the rpc in the proto file. -- [ ] [There is a change description in the release notes](https://github.com/lightningnetwork/lnd/tree/master/docs/release-notes), or `[skip ci]` in the commit message for small changes. +- [ ] [There is a change description in the release notes](https://github.com/lightningnetwork/lnd/tree/master/docs/release-notes), or `[skip ci]` in the commit message for small changes. -📝 Please see our [Contribution Guidelines](https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md) for further guidance. +📝 Please see our [Contribution Guidelines](https://github.com/lightningnetwork/lnd/blob/master/docs/code_contribution_guidelines.md) for further guidance. diff --git a/README.md b/README.md index 184d0a224..e5fa72002 100644 --- a/README.md +++ b/README.md @@ -51,7 +51,7 @@ said, the current status of `lnd`'s BOLT compliance is: The daemon has been designed to be as developer friendly as possible in order to facilitate application development on top of `lnd`. Two primary RPC interfaces are exported: an HTTP REST API, and a [gRPC](https://grpc.io/) -service. The exported API's are not yet stable, so be warned: they may change +service. The exported APIs are not yet stable, so be warned: they may change drastically in the near future. An automatically generated set of documentation for the RPC APIs can be found diff --git a/aezeed/README.md b/aezeed/README.md index b9298b2c3..a1fc21724 100644 --- a/aezeed/README.md +++ b/aezeed/README.md @@ -11,7 +11,7 @@ process. A lack of a birthday means that wallets don’t know how far back to look in the chain to ensure that they derive all the proper user addresses. Additionally, BIP39 use a very weak [KDF](https://en.wikipedia.org/wiki/Key_derivation_function). We use scrypt with modern parameters (n=32768, r=8, p=1). A set of benchmarks has -been added, on my laptop I get about 100ms per attempt): +been added, on my laptop I get about 100ms per attempt: ```shell $ go test -run=XXX -bench=. @@ -48,13 +48,13 @@ the keys of the wallet. The 2 byte timestamp is expressed in Bitcoin Days Genesis, meaning that the number of days since the timestamp in Bitcoin’s genesis block. This -allow us to save space, and also avoid using a wasteful level of +allows us to save space, and also avoid using a wasteful level of granularity. This can currently express time up until 2188. Finally, the entropy is raw entropy that should be used to derive the wallet’s HD root. -## aezeed enciphering/deciperhing +## aezeed enciphering/deciphering Next, we’ll take the plaintext seed described above and encipher it to procure a final cipher text. We’ll then take this cipher text (the diff --git a/docker/README.md b/docker/README.md index 1857af10c..b2f1d1efc 100644 --- a/docker/README.md +++ b/docker/README.md @@ -217,7 +217,7 @@ bob $ lncli --network=simnet channelbalance ``` Now we have open channel in which we sent only one payment, let's imagine -that we sent lots of them and we'd now like to close the channel. Let's do +that we sent lots of them, and we'd now like to close the channel. Let's do it! ```shell # List the "Alice" channel and retrieve "channel_point" which represents @@ -300,7 +300,7 @@ bitcoins. The schema will be following: to "Faucet" then the already created "btcd" node would be sufficient. ``` -First of all you need to run `btcd` node in `testnet` and wait for it to be +First you need to run `btcd` node in `testnet` and wait for it to be synced with test network (`May the Force and Patience be with you`). ```shell # Init bitcoin network env variable: @@ -330,11 +330,11 @@ and send some amount of bitcoins to `Alice`. ### Building standalone docker images Instructions on how to build standalone docker images (for development or -production), outside of `docker-compose`, see the +production), outside `docker-compose`, see the [docker docs](../docs/DOCKER.md). ### Using bitcoind version -If you are using the bitcoind version of the compose file i.e `docker-compose-bitcoind.yml`, follow these additional instructions: +If you are using the bitcoind version of the compose file i.e. `docker-compose-bitcoind.yml`, follow these additional instructions: #### Start Bitcoin Node with bitcoind using Docker Compose To launch the Bitcoin node using bitcoind in the regtest network using Docker Compose, use the following command: diff --git a/docs/DOCKER.md b/docs/DOCKER.md index 3af75c906..eb1fbd1cb 100644 --- a/docs/DOCKER.md +++ b/docs/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: diff --git a/docs/INSTALL.md b/docs/INSTALL.md index 30afa7bdd..819e5708a 100644 --- a/docs/INSTALL.md +++ b/docs/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:
macOS - 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//Library/Application Support/Lnd/lnd.conf` **On Linux, located at:** diff --git a/docs/MAKEFILE.md b/docs/MAKEFILE.md index 7dbef721a..b43088f71 100644 --- a/docs/MAKEFILE.md +++ b/docs/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 diff --git a/docs/code_contribution_guidelines.md b/docs/code_contribution_guidelines.md index 1227f6849..9e4203c8b 100644 --- a/docs/code_contribution_guidelines.md +++ b/docs/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. diff --git a/docs/code_formatting_rules.md b/docs/code_formatting_rules.md index 07b2c24c2..731bb6406 100644 --- a/docs/code_formatting_rules.md +++ b/docs/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`. diff --git a/docs/configuring_tor.md b/docs/configuring_tor.md index c825a21ff..20584124c 100644 --- a/docs/configuring_tor.md +++ b/docs/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). diff --git a/docs/etcd.md b/docs/etcd.md index e72e0f6df..bf1a82998 100644 --- a/docs/etcd.md +++ b/docs/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. diff --git a/docs/fuzz.md b/docs/fuzz.md index bcfc7935d..d781195e5 100644 --- a/docs/fuzz.md +++ b/docs/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 diff --git a/docs/grpc/java.md b/docs/grpc/java.md index 49535ca57..e27a05698 100644 --- a/docs/grpc/java.md +++ b/docs/grpc/java.md @@ -63,7 +63,7 @@ The following dependencies are required. ``` -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 diff --git a/docs/key_import.md b/docs/key_import.md index fd9e62e94..6a3fd8a23 100644 --- a/docs/key_import.md +++ b/docs/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. diff --git a/docs/macaroons.md b/docs/macaroons.md index 291afdc89..c30eb2cf3 100644 --- a/docs/macaroons.md +++ b/docs/macaroons.md @@ -136,7 +136,7 @@ To avoid leaking the macaroon information, `lnd` supports the so called before the `changepassword` command still remain valid. If a user wants to invalidate all previously created macaroons, the `--new_mac_root_key` flag of the `changepassword` command should be used! -* An user of `lncli` will see the returned admin macaroon printed to the screen +* A user of `lncli` will see the returned admin macaroon printed to the screen or saved to a file if the parameter `--save_to=some_file.macaroon` is used. * **Important:** By default, `lnd` will create the macaroon files during the `unlock` phase, if the `--stateless_init` flag is not used. So to avoid diff --git a/docs/postgres.md b/docs/postgres.md index 582c97159..423efc790 100644 --- a/docs/postgres.md +++ b/docs/postgres.md @@ -17,7 +17,7 @@ $ make install ## Configuring Postgres for LND In order for LND to run on Postgres, an empty database should already exist. A -database can be created via the usual ways (psql, pgadmin, etc). A user with +database can be created via the usual ways (psql, pgadmin, etc.). A user with access to this database is also required. Creation of a schema and the tables is handled by LND automatically. diff --git a/docs/psbt.md b/docs/psbt.md index c1b824f50..6c587beaa 100644 --- a/docs/psbt.md +++ b/docs/psbt.md @@ -129,7 +129,7 @@ $ bitcoin-cli decodepsbt cHNidP8BAHECAAAAAeJQY2VLRtutKgQYFUajEKpjFfl0Uyrm6x23Ou Let's now look at how we can implement manual coin selection by using the `fund` command. We again want to send half a coin to -`bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re` but we want to select our inputs +`bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz8re`, but we want to select our inputs manually. The first step is to look at all available UTXOs and choose. To do so, we use @@ -183,7 +183,7 @@ $ lncli wallet psbt fund --outputs='{"bcrt1qjrdns4f5zwkv29ln86plqzs092yd5fg6nsz } ``` -Inspecting this PSBT, we notice that the two inputs were chosen and a large +Inspecting this PSBT, we notice that the two inputs were chosen, and a large change output was added at index 1: ```shell @@ -319,7 +319,7 @@ outputs are used to fund a channel. See This is a step-by-step guide on how to open a channel with `lnd` by using a PSBT as the funding transaction. We will use `bitcoind` to create and sign the transaction just to keep the -example simple. Of course any other PSBT compatible wallet could be used and the +example simple. Of course any other PSBT compatible wallet could be used, and the process would likely be spread out over multiple signing steps. The goal of this example is not to cover each and every possible edge case but to help users of `lnd` understand what inputs the `lncli` utility expects. diff --git a/docs/recovery.md b/docs/recovery.md index 2e9d9f7b2..c99e0ddef 100644 --- a/docs/recovery.md +++ b/docs/recovery.md @@ -193,7 +193,7 @@ rescan. ### Forced In-Place Rescan 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 +there's no existing UTXO or key data in the node's database. However, there are 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 @@ -231,7 +231,7 @@ knows if they have the latest state of a channel or not. Instead, we aim to provide a simple, safe method to allow users to recover the settled funds in their channels in the case of partial or complete data loss. The backups themselves are encrypted using a key derived from the user's seed, this way we -protect privacy of the users channels in the back up state, and ensure that a +protect privacy of the users channels in the backup state, and ensure that a random node can't attempt to import another user's channels. Given a valid SCB, the user will be able to recover funds that are fully @@ -249,7 +249,7 @@ There are multiple ways of obtaining SCBs from `lnd`. The most commonly used method will likely be via the `channel.backup` file that's stored on-disk alongside the rest of the chain data. This is a special file that contains SCB 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 +closed, this file is updated on disk safely (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` @@ -280,7 +280,7 @@ $ lncli --network=simnet exportchanbackup --all $ lncli --network=simnet exportchanbackup --all --output_file=channel.backup ``` -As shown above, a user can either: specify a specific channel to backup, backup +As shown above, a user can either: specify a specific channel to back up, backup all existing channels, or backup directly to an on-disk file. All backups use the same format. diff --git a/docs/release-notes/release-notes-0.14.0.md b/docs/release-notes/release-notes-0.14.0.md index 9d4db2d4b..b6ab86fec 100644 --- a/docs/release-notes/release-notes-0.14.0.md +++ b/docs/release-notes/release-notes-0.14.0.md @@ -226,7 +226,7 @@ documentation](../psbt.md#use-the-batchopenchannel-rpc-for-safe-batch-channel-fu discussion](https://github.com/lightningnetwork/lnd/pull/4685#discussion_r503080709)). This synchronization check is put back now as we want to make the integration test more robust in catching real world situations. This also means it might - take longer to start a `lnd` node when running in `simnet` or `regtest`, + take longer to start an `lnd` node when running in `simnet` or `regtest`, something developers need to watch out from this release. ### Remote signing diff --git a/docs/release.md b/docs/release.md index bfcd3d849..3c205f9ab 100644 --- a/docs/release.md +++ b/docs/release.md @@ -6,11 +6,11 @@ binaries are now reproducible, allowing developers to build the binary on distinct machines, and end up with a byte-for-byte identical binary. However, this wasn't _fully_ solved in `go1.13`, as the build system still includes the directory the binary is built into the binary itself. As a result, our scripts -utilize a work around needed until `go1.13.2`. +utilize a workaround needed until `go1.13.2`. ## Building a New Release -### MacOS +### macOS The first requirement is to have [`docker`](https://www.docker.com/) installed locally and running. The second requirement is to have `make` diff --git a/docs/remote-signing.md b/docs/remote-signing.md index bd5fa7218..0f06463b3 100644 --- a/docs/remote-signing.md +++ b/docs/remote-signing.md @@ -91,9 +91,9 @@ signer> $ lncli wallet accounts list > accounts-signer.json That `accounts-signer.json` file has to be copied to the machine on which "watch-only" will be running. It contains the extended public keys for all of -`lnd`'s accounts (see [required accounts](#required-accounts) ). +`lnd`'s accounts (see [required accounts](#required-accounts)). -A custom macaroon can be baked for the watch-only node so it only gets the +A custom macaroon can be baked for the watch-only node, so it only gets the minimum required permissions on the signer instance: ```shell diff --git a/docs/rest/websockets.md b/docs/rest/websockets.md index f231075f1..ff4d4a3c3 100644 --- a/docs/rest/websockets.md +++ b/docs/rest/websockets.md @@ -17,7 +17,7 @@ what header fields are allowed to be sent. Therefore, the macaroon cannot just be added as a `Grpc-Metadata-Macaroon` header field as it would work with normal REST calls. The browser will just ignore that header field and not send it. -Instead we have added a workaround in `lnd`'s WebSocket proxy that allows +Instead, we have added a workaround in `lnd`'s WebSocket proxy that allows sending the macaroon as a WebSocket "protocol": ```javascript @@ -101,12 +101,12 @@ ws.on('message', function(body) { ## Request-streaming RPCs Starting with `lnd v0.13.0-beta` all RPCs can be used through REST, even those -that are fully bi-directional (e.g. the client can also send multiple request +that are fully bidirectional (e.g. the client can also send multiple request messages to the stream). **Example**: -As an example we show how one can use the bi-directional channel acceptor RPC. +As an example we show how one can use the bidirectional channel acceptor RPC. Through that RPC each incoming channel open request (another peer opening a channel to our node) will be passed in for inspection. We can decide programmatically whether to accept or reject the channel. diff --git a/docs/safety.md b/docs/safety.md index ec59722c9..7164fd9d8 100644 --- a/docs/safety.md +++ b/docs/safety.md @@ -29,7 +29,7 @@ This chapter describes the security/safety mechanisms that are implemented in `lnd`. We encourage every person that is planning on putting mainnet funds into a Lightning Network channel using `lnd` to read this guide carefully. -As of this writing, `lnd` is still in beta and it is considered `#reckless` to +As of this writing, `lnd` is still in beta, and it is considered `#reckless` to put any life altering amounts of BTC into the network. That said, we constantly put in a lot of effort to make `lnd` safer to use and more secure. We will update this documentation with each safety mechanism that @@ -77,7 +77,7 @@ But the node will need to be restored using the ### TLS -By default the two API connections `lnd` offers (gRPC on port 10009 and REST on +By default, the two API connections `lnd` offers (gRPC on port 10009 and REST on port 8080) use TLS with a self-signed certificate for transport level security. Specifying the certificate on the client side (for example `lncli`) is only a protection against man-in-the-middle attacks and does not provide any @@ -211,14 +211,14 @@ line, it is hashed and only the hash (or to be more exact, the BIP32 extended root key) is stored in the `wallet.db` file. There is [a tool being worked on](https://github.com/lightningnetwork/lnd/pull/2373) -that can extract the BIP32 extended root key but currently you cannot restore +that can extract the BIP32 extended root key, but currently you cannot restore lnd with only this root key. Important to know: * Setting a password/passphrase for the aezeed is meant to protect it from an attacker that finds the paper/storage device. Writing down the password alongside the 24 seed words does not enhance the security in any way. - Therefore the password should be stored in a separate place. + Therefore, the password should be stored in a separate place. ### File based backups @@ -231,7 +231,7 @@ those risks. The single most important file that needs to be backed up whenever it changes is the `/data/chain/bitcoin/mainnet/channel.backup` file which holds the Static Channel Backups (SCBs). This file is only updated every time `lnd` -starts, a channel is opened or a channel is closed. +starts, a channel is opened, or a channel is closed. Most consumer Lightning wallet apps upload the file to the cloud automatically. @@ -295,10 +295,9 @@ online. Funds that are in such channels are at great risk, as is described quite dramatically in -[this article](https://medium.com/@gcomxx/get-rid-of-those-zombie-channels-1267d5a2a708?) -. +[this article](https://medium.com/@gcomxx/get-rid-of-those-zombie-channels-1267d5a2a708?). -The TL;DR of the article is that if you have funds in a zombie channel and you +The TL;DR of the article is that if you have funds in a zombie channel, and you need to recover your node after a failure, SCBs won't be able to recover those funds. Because SCB restore [relies on the remote node cooperating](#static-channel-backups-scbs). @@ -328,7 +327,7 @@ fallback way to do it. This option works very well if the new device runs the same operating system on the same (or at least very similar) architecture. If that is the case, the whole `/home//.lnd` directory in Linux (or -`$HOME/Library/Application Support/lnd` in MacOS, `%LOCALAPPDATA%\lnd` in +`$HOME/Library/Application Support/lnd` in macOS, `%LOCALAPPDATA%\lnd` in Windows) can be moved to the new device and `lnd` started there. It is important to shut down `lnd` on the old device before moving the directory! **Not supported/untested** is moving the data directory between different @@ -428,11 +427,11 @@ The following (non-exhaustive) list of things can lead to data corruption: architectures. To avoid most of these factors, it is recommended to store `lnd`'s main data -directory on an Solid State Drive (SSD) of a reliable manufacturer. +directory on a Solid State Drive (SSD) of a reliable manufacturer. An alternative or extension to that is to use a replicated disk setup. Making -sure a power failure does not interrupt the node by running a UPS ( -uninterruptible power supply) might also make sense depending on the reliability -of the local power grid and the amount of funds at stake. +sure a power failure does not interrupt the node by running a UPS +(uninterruptible power supply) might also make sense depending on the +reliability of the local power grid and the amount of funds at stake. ### Don't interrupt `lncli` commands diff --git a/docs/wallet.md b/docs/wallet.md index 8563e52cc..7506be22c 100644 --- a/docs/wallet.md +++ b/docs/wallet.md @@ -115,7 +115,7 @@ of some sort. It will also only work on Unix like file systems that support named pipes. We will use the password manager [`pass`](https://www.passwordstore.org/) as an -example here but it should work similarly with other password managers. +example here, but it should work similarly with other password managers. - Start `lnd` without the flag: ```shell @@ -179,7 +179,7 @@ There is a way to get rid of the need to unlock the wallet password: The Using that flag with **real funds (mainnet) is extremely risky for two reasons**: 1. On first startup a wallet is created automatically. The seed phrase (the 24 - words needed to restore a wallet) is never shown to the user. Therefore if + words needed to restore a wallet) is never shown to the user. Therefore, if the worst thing happens and the hard disk crashes or the wallet file is deleted by accident, **THERE IS NO WAY OF GETTING THE FUNDS BACK**. 2. In addition to the seed not being known to the user, the wallet database is diff --git a/docs/watchtower.md b/docs/watchtower.md index 2bacd53b2..d99eef0c9 100644 --- a/docs/watchtower.md +++ b/docs/watchtower.md @@ -175,7 +175,7 @@ With the addition of the `lncli wtclient` command, users are now able to interact with the watchtower client directly to obtain/modify information about the set of registered watchtowers. -As as example, with the `lncli wtclient tower` command, you can obtain the +As an example, with the `lncli wtclient tower` command, you can obtain the 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. diff --git a/lntest/README.md b/lntest/README.md index c4f702003..ce8218544 100644 --- a/lntest/README.md +++ b/lntest/README.md @@ -84,10 +84,10 @@ Standby nodes are `HarnessNode`s created when initializing the integration test and stay alive across all the test cases. Creating a new node is not without a cost. With block height increasing, it takes significantly longer to initialize a new node and wait for it to be synced. Standby nodes, however, don’t have -this problem as they are digesting blocks all the time. Thus it’s encouraged to +this problem as they are digesting blocks all the time. Thus, it’s encouraged to use standby nodes wherever possible. -Currently there are two standby nodes, Alice and Bob. Their internal states are +Currently, there are two standby nodes, Alice and Bob. Their internal states are recorded and taken into account when `HarnessTest` makes assertions. When making a new test case using `Subtest`, there’s a cleanup function which further validates the current test case has no dangling uncleaned states, such diff --git a/macaroons/README.md b/macaroons/README.md index cf3e7d481..4e2396b74 100644 --- a/macaroons/README.md +++ b/macaroons/README.md @@ -39,7 +39,7 @@ With the root key set up, `lnd` continues with creating three macaroon files: the name might suggest it. The permission `offchain` is needed to pay an invoice which is currently only granted in the admin macaroon. * `readonly.macaroon`: Grants read-only access to all gRPC commands. Could be - given to a monitoring application for example. + given to a monitoring application for example. * `admin.macaroon`: Grants full read and write access to all gRPC commands. This is used by the `lncli` client. diff --git a/mobile/README.md b/mobile/README.md index 4aa0d7e9d..d8627f753 100644 --- a/mobile/README.md +++ b/mobile/README.md @@ -225,7 +225,7 @@ implementation project(":lndmobile", { "default" }) In LND v0.15+ all API methods have prefixed the generated methods with the subserver name. This is required to support subservers with name conflicts. -eg. `QueryScores` is now `AutopilotQueryScores`. `GetBlockHeader` is now `NeutrinoKitGetBlockHeader`. +e.g. `QueryScores` is now `AutopilotQueryScores`. `GetBlockHeader` is now `NeutrinoKitGetBlockHeader`. ## API docs diff --git a/sweep/README.md b/sweep/README.md index 279725474..5c39fa3e8 100644 --- a/sweep/README.md +++ b/sweep/README.md @@ -21,7 +21,7 @@ or the specified budget has been used up. There are two questions when spending a UTXO - how much fees to pay and what the confirmation target is, which gives us the concepts of budget and deadline. This is especially important when sweeping the outputs of a force close -transaction - some of the outputs are time-sensitive, and may result in fund +transaction - some outputs are time-sensitive, and may result in fund loss if not confirmed in time. On the other hand, we don’t want to pay more than what we can get back - if a sweeping transaction spends more than what is meant to be swept, we are losing money due to fees. @@ -80,7 +80,7 @@ flowchart LR `UtxoAggregator` is an interface that handles the batching of inputs. `BudgetAggregator` implements this interface by grouping inputs with the same deadline together. Inputs with the same deadline express the same time -sensitivity so it makes sense to sweep them in the same transaction. Once +sensitivity, so it makes sense to sweep them in the same transaction. Once grouped, inputs in each batch are sorted based on their budgets. The only exception is inputs with the `ExclusiveGroup` flag set, which will be swept alone. @@ -119,7 +119,7 @@ rate, an ending fee rate, and a width (the deadline delta). It's used by the `LinearFeeFunction` implements this interface using a linear function - it calculates a fee rate delta using `(ending_fee_rate - starting_fee_rate) / -deadline`, and increases the fee rate by this delta value everytime a new block +deadline`, and increases the fee rate by this delta value every time a new block arrives. Once the deadline is passed, `LinearFeeFunction` will cap its returning fee rate at the ending fee rate.