mirrors/lnd
1
0
Fork 0
mirror of https://github.com/lightningnetwork/lnd.git synced 2024-11-19 09:53:54 +01:00
Code Issues Projects Releases Wiki Activity

Merge pull request #2 from PaulCapestany/master

Browse Source 
Fixing some README typos
This commit is contained in:
Olaoluwa Osuntokun 2016-01-16 20:57:27 -08:00
commit cabf36e02d
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@ -4,7 +4,7 @@ This repo is preliminary work on a lightning network peer-to-peer node and walle
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). 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 necessary the necessary malleabilty soft-forks are into bitcoin mainnet (may be significantly before if there are any delays in mainnet malleability fix). 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).
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. 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.
@ -16,7 +16,7 @@ At the moment, it only has a single concrete implementation: using btcd's websoc
### channeldb ### 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 sotrage 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). 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 ### cmd / lncli
A command line to query and control a running lnd. Similar to bitcoin-cli A command line to query and control a running lnd. Similar to bitcoin-cli
@ -40,7 +40,7 @@ In-progress update which improves current implementation of channel state machin
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 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 ### lnwire
Library of messages for Lightning Network node to node communcations. Messages for opening and closing channels, as well as updating and revoking channel states are described here. 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 ### shachain
An implementation of Rusty Russell's [64-dimensional shachain](https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt). An implementation of Rusty Russell's [64-dimensional shachain](https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt).