multi: various formatting fixes after changes to Github flavored markdown

docker/README.md

@@ -46,7 +46,7 @@ topology, and send a payment from `Alice` to `Bob`.
                                     connected to different Bitcoin nodes.
 ```
 
-**General workflow is following:** 
+**General workflow is the following:** 
 
  * Create a `btcd` node running on a private `simnet`.
  * Create `Alice`, one of the `lnd` nodes in our simulation network.
@@ -54,8 +54,8 @@ topology, and send a payment from `Alice` to `Bob`.
  * Mine some blocks to send `Alice` some bitcoins.
  * Open channel between `Alice` and `Bob`.
  * Send payment from `Alice` to `Bob`.
- * Close the channel between `Alice` and Bob`.
- * Check that on-chain Bob balance was changed.
+ * Close the channel between `Alice` and `Bob`.
+ * Check that on-chain `Bob` balance was changed.
 
 Start `btcd`, and then create an address for `Alice` that we'll directly mine
 bitcoin into.
@@ -84,11 +84,13 @@ $ docker-compose run btcctl generate 400
 $ docker-compose run btcctl getblockchaininfo | grep -A 1 segwit
 ```
 
-# Check "Alice" balance:
+Check `Alice` balance:
+```
 alice$ lncli walletbalance --witness_only=true
 ```
 
 Connect `Bob` node to `Alice` node.
+
 ```bash
 # Run "Bob" node and log into it:
 $ docker-compose up --no-recreate -d "bob"

docs/code_contribution_guidelines.md

@@ -18,6 +18,7 @@
 6.2. [Licensing of Contributions](#Licensing)<br />
 
 <a name="Overview" />
+
 ### 1. Overview
 
 Developing cryptocurrencies is an exciting endeavor that touches a wide variety
@@ -45,6 +46,7 @@ We highly encourage code contributions, however it is imperative that you adhere
 to the guidelines established on this page.
 
 <a name="MinSkillset" />
+
 ### 2. Minimum Recommended Skillset
 
 The following list is a set of core competencies that we recommend you possess
@@ -73,6 +75,7 @@ understanding of the various aspects involved with cryptography such as the
 security and performance implications.
 
 <a name="ReqReading" />
+
 ### 3. Required Reading
 
 - [Effective Go](http://golang.org/doc/effective_go.html) - The entire lnd 
@@ -97,6 +100,7 @@ comprehensive document explaining the Lightning Network. As a result, it will
 be recommened for newcomers to read first in order to get up to speed. 
 
 <a name="DevelopmentPractices" />
+
 ### 4. Development Practices
 
 Developers are expected to work in their own trees and submit pull requests when
@@ -104,7 +108,8 @@ they feel their feature or bug fix is ready for integration into the  master
 branch.
 
 <a name="ShareEarly" />
-### 4.1. Share Early, Share Often
+
+#### 4.1. Share Early, Share Often
 
 We firmly believe in the share early, share often approach.  The basic premise
 of the approach is to announce your plans **before** you start work, and once
@@ -124,7 +129,8 @@ This approach has several benefits:
   spend rebasing and otherwise trying to keep up with the main code base
 
 <a name="Testing" />
-### 4.2. Testing
+
+#### 4.2. Testing
 
 One of the major design goals of all of lnd's packages and the daemon itself is
 to aim for a high degree of test coverage.  This is financial software so bugs
@@ -159,7 +165,8 @@ A quick summary of test practices follows:
   [`lnd_test.go`](https://github.com/lightningnetwork/lnd/blob/master/lnd_test.go#L181). 
 
 <a name="CodeDocumentation" />
-### 4.3. Code Documentation and Commenting
+
+#### 4.3. Code Documentation and Commenting
 
 - At a minimum every function must be commented with its intended purpose and
   any assumptions that it makes
@@ -173,6 +180,7 @@ A quick summary of test practices follows:
 	to use it?
 - Exported functions should also include detailed information the caller of the
   function will likely need to know and/or understand:<br /><br />
+
 **WRONG**
 ```go
 // generates a revocation key
@@ -206,6 +214,7 @@ func DeriveRevocationPubkey(commitPubKey *btcec.PublicKey,
 - Comments in the body of the code are highly encouraged, but they should
   explain the intention of the code as opposed to just calling out the
   obvious<br /><br />
+
 **WRONG**
 ```Go
 // return err if amt is less than 546
@@ -226,7 +235,8 @@ but it was left as a magic number to show how much of a difference a good
 comment can make.
 
 <a name="ModelGitCommitMessages" />
-### 4.4. Model Git Commit Messages
+
+#### 4.4. Model Git Commit Messages
 
 This project prefers to keep a clean commit history with well-formed commit
 messages.  This section illustrates a model commit message and provides a bit
@@ -281,7 +291,8 @@ determining the scope of a commit at a glance, or when bug hunting to find a
 commit which introduced a bug or regression. 
 
 <a name="CodeSpacing" />
-### 4.5. Code Spacing 
+
+#### 4.5. Code Spacing 
 
 Blocks of code within lnd should be segmented into logical stanzas of
 operation. Such spacing makes the code easier to follow at a skim, and reduces
@@ -289,7 +300,7 @@ unnecessary line noise. Coupled with the commenting scheme specified above,
 proper spacing allows readers to quickly scan code, extracting semantics quickly.
 Functions should _not_ just be layed out as a bare contiguous block of code. 
 
-- **Wrong**   
+**WRONG**   
 ```go
 	witness := make([][]byte, 4)
 	witness[0] = nil
@@ -303,7 +314,7 @@ Functions should _not_ just be layed out as a bare contiguous block of code.
 	witness[3] = witnessScript
 	return witness
 ```
-- **Right** 
+**RIGHT** 
 ```go
 	witness := make([][]byte, 4)
 
@@ -330,7 +341,8 @@ Functions should _not_ just be layed out as a bare contiguous block of code.
 ```
 
 <a name="Protobuf" />
-### 4.5.6. Protobuf Compilation
+
+#### 4.5.6. Protobuf Compilation
 
 The `lnd` project uses `protobuf`, and its extension [`gRPC`](www.grpc.io) in
 several areas and as the primary RPC interface. In order to ensure uniformity
@@ -356,13 +368,15 @@ itself, and uses a `snake_case` style of name formatting. All added or modified
 `proto` fields should adhere to the format above.
 
 <a name="CodeApproval" />
+
 ### 5. Code Approval Process
 
 This section describes the code approval process that is used for code
 contributions.  This is how to get your changes into lnd.
 
 <a name="CodeReview" />
-### 5.1. Code Review
+
+#### 5.1. Code Review
 
 All code which is submitted will need to be reviewed before inclusion into the
 master branch.  This process is performed by the project maintainers and usually
@@ -397,7 +411,8 @@ checks which are generally performed as follows:
   consensus
 
 <a name="CodeRework" />
-### 5.2. Rework Code (if needed)
+
+#### 5.2. Rework Code (if needed)
 
 After the code review, the change will be accepted immediately if no issues are
 found.  If there are any concerns or questions, you will be provided with
@@ -409,7 +424,8 @@ make the necessary changes.
 This process will continue until the code is finally accepted.
 
 <a name="CodeAcceptance" />
-### 5.3. Acceptance
+
+#### 5.3. Acceptance
 
 Once your code is accepted, it will be integrated with the master branch.
 Typically it will be rebased and fast-forward merged to master as we prefer to
@@ -420,10 +436,12 @@ the master branch and the pull request will be closed.
 Rejoice as you will now be listed as a [contributor](https://github.com/lightningnetwork/lnd/graphs/contributors)!
 
 <a name="Standards" />
+
 ### 6. Contribution Standards
 
 <a name="Checklist" />
-### 6.1. Contribution Checklist
+
+#### 6.1. Contribution Checklist
 
 - [&nbsp;&nbsp;] All changes are Go version 1.5 compliant
 - [&nbsp;&nbsp;] The code being submitted is commented according to the
@@ -441,7 +459,8 @@ Rejoice as you will now be listed as a [contributor](https://github.com/lightnin
   report any **new** issues that did not already exist
 
 <a name="Licensing" />
-### 6.2. Licensing of Contributions
+
+#### 6.2. Licensing of Contributions
 ****
 All contributions must be licensed with the
 [MIT license](https://github.com/lightningnetwork/lnd/blob/master/LICENSE).  This is

docs/grpc/javascript.md

@@ -1,4 +1,4 @@
-# How to write a simple `lnd` client in Javascript using `node.js
+# How to write a simple `lnd` client in Javascript using `node.js`
 
 First, you'll need to initialize a simple nodejs project: