multi: various formatting fixes after changes to Github flavored markdown

This commit is contained in:
Marty Jones 2017-03-27 18:20:31 -05:00 committed by Olaoluwa Osuntokun
parent 505421db2c
commit 18052f9f19
4 changed files with 53 additions and 32 deletions

@ -6,9 +6,9 @@ automatically by their `docker-compose` config file.
### Prerequisites
Name | Version
--------|---------
docker-compose | 1.9.0
docker | 1.13.0
--------|---------
docker-compose | 1.9.0
docker | 1.13.0
### Table of content
* [Create lightning network cluster](#create-lightning-network-cluster)
@ -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"

@ -1,11 +1,11 @@
#Installation for Lnd and Btcd
# Installation for Lnd and Btcd
### If Glide isn't installed, install it:
```
$ go get -u github.com/Masterminds/glide
```
###Install lnd:
### Install lnd:
```
$ cd $GOPATH
$ git clone https://github.com/lightningnetwork/lnd $GOPATH/src/github.com/lightningnetwork/lnd
@ -14,7 +14,7 @@ $ glide install
$ go install . ./cmd/...
```
###Create lnd.conf:
### Create lnd.conf:
**On MacOS, located at:**
/Users/[username]/Library/Application Support/Lnd/lnd.conf
@ -31,25 +31,25 @@ btcdhost=127.0.0.1
debuglevel=debug
```
###Install btcutil: (must be from roasbeef fork, not from btcsuite)
### Install btcutil: (must be from roasbeef fork, not from btcsuite)
```
$ go get -u github.com/roasbeef/btcutil
```
###Install btcd: (must be from roasbeef fork, not from btcsuite)
### Install btcd: (must be from roasbeef fork, not from btcsuite)
```
$ cd $GOPATH/src/github.com/roasbeef/btcd
$ glide install
$ go install . ./cmd/...
```
###Start btcd (will create rpc.cert and default btcd.conf):
### Start btcd (will create rpc.cert and default btcd.conf):
```
$ btcd --testnet --txindex --rpcuser=kek --rpcpass=kek
```
(Note: It may take several minutes to find segwit-enabled peers.)
###Add a limited username and password to btcd.conf and restart
### Add a limited username and password to btcd.conf and restart
(Note: Replace `kek` with the username and password you prefer.)
**On Linux:**
@ -77,22 +77,22 @@ $ btcctl --testnet stop
$ btcd --testnet
```
###Check to see that peers are connected:
### Check to see that peers are connected:
```
$ btcctl --testnet getpeerinfo | more
```
###Start Lnd: (Once btcd has synced testnet)
### Start Lnd: (Once btcd has synced testnet)
```
$ lnd --testnet
```
###Start Lnd on Simnet: (Doesnt require testnet syncing.)
### Start Lnd on Simnet: (Doesnt require testnet syncing.)
```
$ lnd --simnet --debughtlc
```
####Accurate as of:
#### Accurate as of:
roasbeef/btcd commit: 707a14a
roasbeef/btcutil commit: d347e49

@ -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

@ -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: