Skip to content

replace all instances of 'ln' with 'lightning' in README.md #6

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
shea256 wants to merge 1 commit into from
Closed

replace all instances of 'ln' with 'lightning' in README.md #6

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 18 additions & 18 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,20 +1,20 @@
# lnd - Lightning Network Daemon
# Lightning Network Daemon
Copy link
Copy Markdown
Member

@Roasbeef Roasbeef Feb 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lnd here should be kept, it's the name of the daemon. All other swaps below from lnd to lightningd should also be reverted.


This repo is preliminary work on a lightning network peer-to-peer node and wallet.

It currently is being designed for testnet-L, a test network where all txids are normalized. The plan is to eventually use the agreed longer-term solution (segwit?), but we want to not be concerned with updates to segwit, so we're running with this. Normalized txids fixes malleability but isn't something that will/can be integrated to the existing bitcoin network cleanly (so it's a good way to ensure testing-only before segwit is finalized, which solves the problem too).

This version of Lnd is not yet fully-operational, but a proof of concept on testnet-L 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).
This version of lightningd is not yet fully-operational, but a proof of concept on testnet-L 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).

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.

## Installation

* If necessary, install Go according to the installation instructions here: http://golang.org/doc/install. It is recommended to add `$GOPATH/bin` to your `PATH` at this point.
* Run the following command to obtain and install lnd, lncli, lnshell and all dependencies:
* Run the following command to obtain and install lightningd, lightningcli, lightningshell and all dependencies:
Copy link
Copy Markdown
Member

@Roasbeef Roasbeef Feb 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please revert this line, as the packages are purposefully named.


```
go get -u -v github.com/lightningnetwork/lnd/...
go get -u -v github.com/lightningnetwork/lightningd/...
Copy link
Copy Markdown
Member

@Roasbeef Roasbeef Feb 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing this without changing the name of the repo will cause future go get ... calls to fail.

```

## Packages and Utilities
Expand All @@ -27,34 +27,34 @@ At the moment, it only has a single concrete implementation: using btcd's websoc

### 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).
lightningd'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 / lightningcli
A command line to query and control a running lightningd. 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.
### cmd / lightningshell
Interactive shell for commands to direct the lightningd node. Will probably be merged into lightningd 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.
This is useful for the hashed secrets in lightning 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.
### lightningdc
Library for authenticated encrypted communication between lightning 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
### lightningrpc

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.
lightningd'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, lightningd 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
### lightningstate
In-progress update which improves current implementation of channel state machine to allow for higher throughput.

### lnwallet
### lightningwallet

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`.
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 lightningwallet 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 `lightningstate`.

### lnwire
### lightningwire
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
Expand Down