akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

README: update readme to latest project state

Browse Source
This commit is contained in:
Olaoluwa Osuntokun 2017-01-10 12:14:37 -08:00
parent f1e23748c9
commit e37b848f36
No known key found for this signature in database
GPG Key ID: 9CC5B105D03521A2
1 changed files with 64 additions and 55 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

119
README.md
View File

@ -1,21 +1,63 @@
# lnd - Lightning Network Daemon
# `lnd` - the Lightning Network Daemon
[![Build Status](https://travis-ci.org/lightningnetwork/lnd.svg?branch=master)](https://travis-ci.org/lightningnetwork/lnd)
This repo is preliminary work on a lightning network peer-to-peer node and wallet.
It's currently being tested on Segnet4, where malleability has been solved with segwit.
`lnd` is a complete implementation of a node on the [Lightning
Network](lightning.network). `lnd` is currently deployed on the Bitcoin Test
Network (testnet4) and utilizes an upcoming upgrade to Bitcoin: Segregated
Witness. The project's codebase uses the
[btcsuite](https://github.com/btcsuite/) set of Bitcoin libraries, and is
currently dependant on [btcd](https://github.com/btcsuite/btcd).
This version of Lnd is not yet fully-operational, but a proof of concept on Segnet4 will likely exist soon. The projection is it will be operational before the necessary malleability soft-forks are into bitcoin mainnet (may be significantly before if there are any delays in mainnet malleability fix).
The Lightning Network Daemon (`lnd`) is capable of: creating channels, closing
channels, completely managing all channel states (including the exceptional
ones!), maintaining a fully authenticated+validated channel graph, performing
path finding within the network, passively forwarding incoming payments, and
sending outgoing [onion-encrypted
payments](https://github.com/lightningnetwork/lightning-onion) through the
network.
Don't try to port it to mainnet or an altcoin and use it today! No really. Lightning transactions will be fast, but for now, please wait just a little bit.
## Lightning Network Specification Compliance
`lnd` doesn't yet _fully_ conform to the [Lightning Network specification
(BOLT's)](https://github.com/lightningnetwork/lightning-rfc). BOLT stands for:
Basic of Lightning Technologies. The specifications are currently being drafted
by several groups of implementers based around the world including the
developers of `lnd`. The set of specification documents as well as our
implementation of the specification are still a work-in-progress. With that
said, `lnd` the current status of `lnd`'s BOLT compliance is:
- [ ] BOLT 1: Base Protocol
* `lnd` currently utilizes a distinct wire format which was created before
the emgergence of the current draft of BOLT specifications. We don't
have an `init` message, but we do have analogues to all the other
defined message types.
- [ ] BOLT 2: Peer Protocol for Channel Management
* `lnd` implements all the functionality defined within the document,
however we currently use a different set of wire messages. Additionally,
`lnd` uses a distinct commitment update state-machine and doesn't yet
support dynamically updating commitment fees.
- [ ] BOLT 3: Bitcoin Transaction and Script Formats
* `lnd` currently uses a commitment design from a prior iteration of the
protocol. Revocation secret generation is handled by `elkrem` and our
scripts are slightly different.
- [X] BOLT 4: Onion Routing Protocol
- [X] BOLT 5: Recommendations for On-chain Transaction Handling
- [X] BOLT 7: P2P Node and Channel Discovery
- [X] BOLT 8: Encrypted and Authenticated Transport
## Installation
* In order to build form source, the following build dependencies are required:
* **Go 1.5 or 1.6**
Installation instructions can be found here: http://golang.org/doc/install. It is recommended to add `$GOPATH/bin` to your `PATH` at this point.
**Note:** If you are building with Go 1.5, then you'll need to enable the vendor experiment by setting the `GO15VENDOREXPERIMENT` environment variable to `1`. If you're using Go 1.6 or later, then it is safe to skip this step.
Installation instructions can be found here: http://golang.org/doc/install.
It is recommended to add `$GOPATH/bin` to your `PATH` at this point.
**Note:** If you are building with Go 1.5, then you'll need to enable the
vendor experiment by setting the `GO15VENDOREXPERIMENT` environment
variable to `1`. If you're using Go 1.6 or later, then it is safe to skip
this step.
* **Glide**
This project uses `Glide` to manage dependencies as well as to provide *reproducible builds*.
@ -24,10 +66,14 @@ Don't try to port it to mainnet or an altcoin and use it today! No really. Lig
`$ go get -u github.com/Masterminds/glide`
* **btcd**
This project currently requires `btcd` with segwit support, which is not merged yet. To install,
please see [the installation instructions](docs/INSTALL.md).
This project currently requires `btcd` with segwit support, which is not
yet merged into the master branch. Instead,
[roasbeef](https://github.com/roasbeef/btcd) maintains a fork with his
segwit implementation applied. To install, please see [the installation
instructions](docs/INSTALL.md).
With the preliminary steps completed, to install `lnd`, `lncli`, and all related dependencies run the following commands:
With the preliminary steps completed, to install `lnd`, `lncli`, and all
related dependencies run the following commands:
```
$ git clone https://github.com/lightningnetwork/lnd $GOPATH/src/github.com/lightningnetwork/lnd
@ -37,55 +83,18 @@ $ go install . ./cmd/...
```
## Updating
To update your version of `lnd` to the latest version run the following commands:
To update your version of `lnd` to the latest version run the following
commands:
```
$ cd $GOPATH/src/github.com/lightningnetwork/lnd
$ git pull && glide install
$ go install . ./cmd/...
```
## Packages and Utilities
## IRC
* irc.freenode.net
* channel #lnd
* [webchat](https://webchat.freenode.net/?channels=lnd)
### chainntfs
A package centered around a generic interface for receiving transaction/confirmation based notifications concerning the blockchain. Such notifications are required in order for pending payment channels to be notified once the funding transaction gains a specified number of confirmations, and in order to catch a counter-party attempting a non-cooperative close using a past commitment transaction to steal funds.
At the moment, it only has a single concrete implementation: using btcd's websockets notifications. However, more implementations of the interface are planned, such as electrum, polling via JSON-RPC, Bitcoin Core's ZeroMQ notifications, and more.
### channeldb
lnd's primary datastore. It uses a generic interface defined in [walletdb](https://godoc.org/github.com/btcsuite/btcwallet/walletdb) allowing for usage of any storage backend which adheres to the interface. The current concrete implementation used is driven by [bolt](https://github.com/boltdb/bolt). `channeldb` is responsible for storing state such as meta-data concerning the current open channels, closed channels, past routes we used, fee schedules within the network, and information about remote peers (ID, uptime, reputation, etc).
### cmd / lncli
A command line to query and control a running lnd. Similar to bitcoin-cli
### cmd / lnshell
Interactive shell for commands to direct the lnd node. Will probably be merged into lnd soon as a command line option.
### elkrem
Library to send and receive a tree structure of hashes which can be sequentially revealed. If you want to send N secrets, you only need to send N secrets (no penalty there) but the receiver only needs to store log2(N) hashes, and can quickly compute any previous secret from those.
This is useful for the hashed secrets in LN payment channels.
### lndc
Library for authenticated encrypted communication between LN nodes. It uses chacha20_poly1305 for the symmetric cipher, and the secp256k1 curve used in bitcoin for public keys. No signing is used, only two ECDH calculations: first with ephemeral key pairs and second with persistent identifying public keys.
### lnrpc
lnd's RPC interface. Currently [gRPC](http://www.grpc.io/), a high-performance RPC framework is used. gRPC provides features such as a stub-based client interface in several languages, streaming RPCs, payload agnostic request/response handling, and more. In addition to gRPC, lnd will also offer a basic REST-based http RPC interface. For now, connections are not encrypted, or authenticated. For authentication, [macaroons](http://research.google.com/pubs/pub41892.html) will likely be integrated due to their simplicity, flexibility, and expressiveness.
### lnstate
In-progress update which improves current implementation of channel state machine to allow for higher throughput.
### lnwallet
An application specific, yet general Bitcoin wallet which understands all the fancy script, and transaction formats needed to transact on the Lightning Network. The interface, and interaction with the core wallet logic has been designed independent of any peer-to-peer communication. The goal is to make lnwallet self-contained, and easily embeddable within future projects interacting with the Lightning Network. The current state machine for channel updates is blocking, only allowing one pending update at a time. This will soon be replaced in favor of the highly concurrent, non-blocking state machine within `lnstate`.
### lnwire
Library of messages for Lightning Network node to node communications. Messages for opening and closing channels, as well as updating and revoking channel states are described here.
### shachain
An implementation of Rusty Russell's [64-dimensional shachain](https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt).
### uspv
Wallet library to connect to bitcoin nodes and build a local SPV and wallet transaction state.
## License
`lnd` is licensed under the [MIT license](https://github.com/lightningnetwork/lnd/blob/master/LICENSE).