multi: various formatting fixes after changes to Github flavored markdown
This commit is contained in:
parent
505421db2c
commit
18052f9f19
@ -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: (Doesn’t require testnet syncing.)
|
||||
### Start Lnd on Simnet: (Doesn’t 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
|
||||
|
||||
- [ ] All changes are Go version 1.5 compliant
|
||||
- [ ] 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:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user